[도메인 주도 개발 시작하기: DDD 핵심 개념 정리부터 구현까지] 9. 도메인 모델과 바운디드 컨텍스트

최범균 님의 "도메인 주도 개발 시작하기: DDD 핵심 개념 정리부터 구현까지" 책을 정리한 포스팅 입니다.

 

1. 도메인 모델과 경계

• 같은 엔티티라도 각각 다른 상위 도메인에 속하게 되면, 의미가 달라짐
• ✅ 각 도메인에서 역할과 책임, 속성, 용어가 달라짐.

 

예) 상품

• 카탈로그: 보여주기용 정보 (상품명, 이미지, 옵션 등)
• 창고: 실물 재고 추적용 정보 (SKU, 수량 등)

 

예) 회원

• 주문: 주문자
• 배송: 보내는 사람

 

2. 바운디드 컨텍스트

• 하나의 도메인 모델에 일관되게 적용되는 경계
• ✅ 모델은 특정한 컨텍스트 하에서 완전한 의미를 가짐
• ➡️ 올바른 도메인 모델을 개발하려면 하위 도메인마다 모델을 만들어야 함

내용	설명
필요성	하위 도메인마다 요구사항/규칙/용어가 다름
구분 기준	사용하는 용어가 다른지, 조직의 팀 구조, 기술적 복잡도 등
구현 시 참고사항	✅ 하위 도메인 1 = N 바운디드 컨텍스트 가능 ✅ 하나의 바운디드 컨텍스트에 여러 하위 도메인을 담기도 함

 

3. 바운디드 컨텍스트 구현

• 도메인 기능을 사용자에게 제공하는 데 필요한 모든 계층

구성 요소	설명
표현 영역 (UI/API)	REST/gRPC Controller, 요청 진입점
응용 서비스	유즈케이스 구현부, 도메인 호출
도메인 모델	핵심 비즈니스 로직 (Aggregate, Entity, VO 등)
인프라	DB, MQ, 외부 API, Persistence Adapter 등

 

4. 바운디드 컨텍스트 간 통합

• 기능 추가로 인해 바운디드 컨텍스트에 하위 도메인이 추가될 수 있음
• ✅ 각 바운디드 컨텍스트의 도메인 모델이 서로 다를 수 있음
• ➡️ 경계를 넘을 때는 번역과 계약이 필요함

 

통합 원칙

원칙	목적	구현 패턴
Anti-Corrouption Layer	경계 밖 모델을 들여오지 않기	DTO/스키마를 내부 유비쿼터스 언어로 변환
ID 기반 참조	결합도 최소화	- ID로만 연결 - 컨텍스트 간 객체/스키마 공유 금지
SoT 단일화	데이터 진실 원천 명확화

구분	권장 기본	보완/주의
내부 컨텍스트 쓰기	한 트랜잭션으로 처리	같은 컨텍스트라도 여러 애그리거트를 동시에 갱신해야 하면 사가/이벤트 고려
교차 컨텍스트 쓰기	사가(오케스트레이션) + 이벤트 기반 + 보상 트랜잭션	✅ 멱등성 키, Outbox/Inbox, 재시도/타임아웃, 설계 필수 ❌ 2PC 지양
교차 컨텍스트 읽기	동기 요청 + DTO + ACL(번역)	✅ ID 참조 + 번역(ACL) 로 내부 언어로 변환 ❌ 외부 모델 복붙 금지

 

예시) 보상 트랜잭션

설명

• 이미 실행된 트랜잭션을 완전히 "취소"할 수 없을 때, 그 영향을 반대 방향으로 상쇄하는 별도의 트랜잭션
• 롤백이 불가능하거나 현실적으로 너무 복잡한 분산 환경에서, 실패한 흐름을 되돌리기 위한 보정 작업
• ✅ 실패를 감지 한 서비스는 보상 이벤트를 발행하여 해당 이벤트 처리 서비스에서 보상 트랜잭션을 실행하도록 해야 함

 

시나리오

• 서비스: Order → Inventory → Payment
• 정상 흐름: OrderCreated → InventoryReserved → PaymentAuthorized → OrderConfirmed
• 실패 흐름: PaymentFailed 발생 → 보상
  • Inventory: ReleaseReservation (재고 롤백)
  • Order: CancelOrder (주문 취소)

 

 

5. 바운디드 컨텍스트 간 관계

개념	설명
Upstream	공급자. API나 도메인 모델을 공개함.
Downstream	소비자. 그 API를 이용함.

 

Open Host Service

• 각 서비스를 통합
• 상류 컴포넌트의 서비스는 상류 바운디드 컨텍스트의 도메인 모델을 따름