architecture
-
DAO·DTO·VO 한 페이지 — 역할로 가르고 예제로 굳히기
OrderDAO·OrderDTO·OrderVO가 한 프로젝트에 나란히 있으면 누가 무엇인지 헷갈린다. 이름이 아니라 역할로 보면 갈라진다. 한 장 비교표부터 DAO의 인터페이스 경계와 Repository와의 차이, 엔티티를 그대로 노출하면 생기는…
-
[아키텍처 최종장] MVC·MVP·MVVM에서 Clean·Hexagonal, 그리고 MSA까지 — 결국 ‘무엇을 어디에 둘까’의 문제
MVC·MVP·MVVM은 C·P·VM만 다르다. Repository와 Active Record는 쿼리 실행 레이어의 위치가 다르다. Clean·Hexagonal은 층위가 다르고, EDA·MSA는 그 경계를 서비스로 쪼갠 것 — 아키텍처 시리즈를 한 장으로…
-
[Flutter × 채팅] 낙관적 UI와 clientMsgId — 서버 멱등키가 클라이언트에서 중복 제거로 완성되는 지점
이중 쓰기(WS 릴레이 + REST 영속화)를 하면 내가 보낸 메시지가 WS로 되돌아와 중복된다. Flutter 앱 Bibleana가 clientMsgId 하나로 낙관적 UI와 에코 dedupe를 잇는 방법, single-flight…
-
[채팅 백엔드 설계] 게이트웨이를 일부러 멍청하게 — 실시간 릴레이와 영속화를 분리한 이유
채팅 백엔드에서 실시간 전달과 메시지 영속화를 한 서비스에 묶으면 DB 장애가 실시간을 죽이고 스케일링이 어려워진다. room-gateway를 DB도 비즈니스 로직도 없는 ‘dumb pipe’로 두고, 클라이언트가 WS…
-
[설계 판단] 서비스 분리는 비즈니스 도메인 중심으로 해야 한다
결론 먼저 서비스 분리는 비즈니스 도메인에 따라 수행하는 것이 적합하다. 이는 각 서비스가 특정 도메인에 집중할 수 있게 해주며, 서비스 간 의존성을 낮추는 장점이 있다.…