DDD 적용과 한계
약 75초
바운디드 컨텍스트·이벤트 분리 경험 + 학습 비용 솔직하게 설명
학교 팀 프로젝트에서 도메인 주도 설계를 처음 적용해봤습니다. 초반에 Order, Payment, Inventory를 한 서비스에 넣었다가 주문 상태 변경이 재고와 결제를 동시에 건드리면서 코드가 얽히기 시작했습니다. 바운디드 컨텍스트를 나눠 주문 컨텍스트는 결제 완료 이벤트만 수신하도록 바꿨고, 애그리거트 루트를 통해서만 상태를 변경하는 규칙을 팀에 공유했습니다. 분리 후 각 컨텍스트가 독립적으로 테스트 가능해졌고, PR 리뷰에서 경계를 벗어나는 참조를 서로 잡아주는 문화가 생겼습니다. 다만 팀원 모두가 바운디드 컨텍스트 경계를 다르게 이해하면 이벤트 흐름이 혼란스러워지는 상황도 겪었고, 공통 언어를 문서로 먼저 정리해야 한다는 걸 배웠습니다.
학습 비용과 설계 오버헤드가 소규모 팀에는 부담이 될 수 있어서, 도메인이 복잡하고 팀 규모가 일정 이상일 때 진가를 발휘하는 방법론이라고 봅니다.