「도메인 주도 개발 시작하기」9장 도메인 모델과 바운디드 컨텍스트

🎈 9.1. 도메인 모델과 경계

하위 도메인마다 같은 용어라도 의미가 다르고 같은 대상이라도 지칭하는 용어가 다를 수 있기 때문에 한 개의 모델로 모든 하위 도메인을 표현하려는 시도는 올바르지 않음. 

 

모델은 특정한 컨텍스트(문맥) 하에서 완전한 의미를 갖는다. 같은 제품이라도 카탈로그 컨텍스트와 재고 컨텍스트에서 의미가 다르다. 

이렇게 구분되는 경계를 갖는 컨텍스트를 DDD에서는 바운디드 컨텍스트라고 부른다. 

 

🎈 9.2. 바운디드 컨텍스트 

하위 도메인과 바운디드 컨텍스트가 일대인 관계를 갖지 않을 때가 많다. 

 

주문 하위 도메인에 주문, 결제 금액 계산 바운디드 컨텍스트가 존재할 수도 있고, 

카탈로그, 재고 도메인을 하나의 바운디드 컨텍스트 상품에서 개발할 수도 있다. 

 

바운디드 컨텍스트는 도메인 모델을 구분하는 경계가 되기 때문에 바운디드 컨텍스트는 구현하는 하위 도메인에 알맞은 모델을 포함한다. 

 

🎈 9.3. 바운디드 컨텍스트 구현

바운디드 컨텍스트는 도메인 기능을 사용자에게 제공하는 데 필요한 표현 영역, 응용 서비스, 인프라스트럭처 영역을 모두 포함한다. 

 

서비스-DAO 구조를 사용하면 도메인 기능이 서비스에 흩어지게 되지만 도메인 기능이 단순하면 서비스-DAO로 구성된 CRUD 방식 사용해도 코드 유지보수에 문제 되지 않는다. 

 

CQRS: Command Query Reponsibility Segregation

상태를 변경하는 명령 기능과 내용을 조회하는 쿼리 기능을 위한 모델을 구분하는 패턴.

 

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

카탈로그 도메인에서 추천 시스템을 도입하면 카탈로그 하위 도메인에 카탈로그를 위한 바운디드 컨텍스트와 추천 기능을 위한 바운디드 컨텍스트가 생긴다. 

REST API를 호출하는 것은 두 바운디드 컨텍스트를 '직접' 통합하는 방법. 

메시지 큐를 사용해 간접적으로 통합할 수 있음. 

두 바운디드 컨텍스트를 개발하는 킴은 메시징 큐에 담을 데이터의 구조를 협의하게 되는데 그 큐를 누가 제공하느냐에 따라 데이터 구조가 결정됨. 한쪽에서 메시지를 출판하고 다른 쪽에서 메시지를 구독하는 출판/구독 모델을 따름. 

큐를 통해 메시지 전달하는 것은 비동기라는 점을 제외하면 REST API를 사용해서 데이터 전달하는 것과 차이 없음. 

 

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

상류 컴포넌트는 보통 하류 컴포넌트가 사용할 수 있는 통신 프로토콜을 정의하고 이를 공개함. 

 

상류 팀의 하류 팀이 다수 존재하면 API 만들고 서비스 형태로 공개해서 일관 성 유지하는 공개 호스트 서비스

 

두 바운디드 컨텍스트가 같은 모델을 공유하는 모델을 '공유 커널'이라고 부름.

중복을 줄여준다는 장점 있지만 두 팀이 밀접한 관계를 유지해야 함. 

 

독립 방식: 서로 통합하지 않는 방식. 두 바컨 간의 통합이 수동으로 이루어짐. ex) 온라인 쇼핑몰 솔루션과 외부의 ERP 서비스를 사용하고 있는 경우. 

 

🎈 9.6. 컨텍스트 맵

컨텍스트 맵: 바운디드 컨텍스트 간의 관계를 표시한 것.