9.1 도메인 모델과 경계
처음 도메인 모델을 만들 때 빠지기 쉬운 함정이 도메인을 완벽하게 표현하는 단일 모델을 만드는 시도를 하는 것이다. - p.276
예를 들어 회원 도메인에서 회원일지라도 북마크 도메인에서는 작성자,
알림 도메인에서는 수신자 처럼 다양한 의미를 가질 수 있다.
모델은 특정한 컨텍스트 하에서 완전한 의미를 가진다. 이렇게 구분되는 경계를 가지는 컨텍스트를 DDD에서는바운디드 컨텍스트
라고 부른다.
9.2 바운디드 컨텍스트
- 애그리거트와 바운디드 컨텍스트는 다르다!
- 바운디드 컨텍스트는 용어를 기준으로 구분한다.
9.3 바운디드 컨텍스트 구현
- 바운디드 컨텍스트 = 표현 영역 + 응용 서비스 + 도메인 영역 + 인프라스트럭처 + DB 테이블 + …
- 모든 바운디드 컨텍스트에 같은 아키텍처를 적용할 필요는 없음
- 한 바운디드 컨텍스트에서도 DDD 방식과 CRUD 방식을 혼용할 수 있음
- CQRS!
9.4 바운디드 컨텍스트 간 통합
방법 1. REST API 호출
- 두 바운디드 컨텍스트를 직접 통합하는 방법
방법 2. Message Queue
- 간접 통합 방식
- Pub/Sub
9.5 바운디드 컨텍스트 간 관계
- 연결된 두 바운디드 컨텍스트 중 가장 흔한 관계는 한쪽에서 API를 제공하고 다른 한쪽에서 그 API를 호출하는 관계
- REST API 가 대표적이다.
- 이 관계에서 API 를 사용하는 바운디드 컨텍스트는 API 를 제공하는 바운디드 컨텍스트에 의존하게 된다.
9.6 컨텍스트 맵

- 바운디드 컨텍스트의 경계/ 관계를 드러내는 그림