하위 도메인마다 다른 모델을 만들어야 한다.
한 도메인은 다시 여러 하위 도메인으로 구분되기 때문에 한 개의 모델로 여러 하위 도메인을 모두 표현하려고 하면 안된다.
논리적으로 같은 존재처럼 보이지만 하위 도메인에 따라 다른 용어를 사용하는 경우도 있다.
- 각 모델은 명시적으로 구본되는 경계를 가져서 섞이지 않도록 해야한다.
- 모델은 특정한 컨텍스트(문맥) 하에서 완전한 의미를 갖는다.
- 구분되는 경계를 갖는 컨텍스트를 DDD에서는 바운디드 컨텍스트라고 부른다.
바운디드 컨텍스트는 도메인 모델을 구분하는 경계다.
바운디드 컨텍스트는 모델의 경계를 결정하며 한 개의 바운디드 컨텍스트는 논리적으로 한 개의 모델을 갖는다.
또한 실제로 사용자에게 기능을 제공하는 물리적 시스템을 도메인 모델은 바운디드 컨텍스트 안에서 도메인을 구현한다.
바운디드 컨텍스트는 기업의 팀 조직 구조에 따라 결정되기도 한다.
여러 하위 도메인을 하나의 바운디드 컨텍스트에서 개발할 때 하위 도메인의 모델이 섞이지 않도록 주의해야 한다.
비록 한 개의 바운디드 컨텍스트가 여러 하위 도메인을 포함하더라도 하위 도메인마다 구분되는 패키지를 갖도록 구현해야한다.
바운디드 컨텍스트는 도메인 모델을 구분하는 경계가 되기 때문에 하위 도메인에 알맞은 모델을 포험하여 구현하게 된다.
모든 바운디드 컨텍스트를 도메인 주도로 개발할 필요는 없다.
바운디드 컨텍스트는 도메인 모델뿐만 아니라 표현 영역, 응용 서비스, 인프라스트럭처 영역을 모두 포함한다.
모든 바운디드 컨텍스트를 도메인 주도로 개발할 필요는 없다.
도메인 기능이 복잡하지 않고 단순하다면 서비스-DAO 방식의 CRUD 방식을 사용해도 문제가 되지 않는다.
한 바운디드 컨텍스트에서 두 방식을 혼합해서 사용할 수도 있따.
대표적인 예악 CQRS(Command Query Responsibility Segregation)로 명령 기능과 조회 쿼리 기능을 위한 모델을 구분하는 패턴이다.
다은과 같이 상태 변경과 관련된 기능은 도메인 모델 기반으로 구현하고 조회 기능은 서비스-DAO를 이용해 구현할 수 있다.
각 바운디드 컨텍스트는 서로 다른 구현 기술을 사용할 수 있으며 반드시 사용자에게 보여지는 UI를 가지고 있어야 하는 것은 아니다.
웹 브라우저에서 REST API를 직접 호출해서 JSON 데이터를 가공할 수도 있고 UI 서버를 두고 바운디드 컨텍스트와 통신하는 방법도 있다.
관련된 바운디드 컨텍스트를 REST API나 메시징을 통해 통합 가능하다.
카탈로그 하위 도메인에 개인화 추천 기능을 도입해 기존 카탈라고를 위한 바운디드 컨텍스트와 추천 기능을 위한 바운디드 컨텍스트가 있다.
두 팀이 관련된 바운디드 컨텍스트를 개발하면서 자연스럽게 두 바운디드 컨텍스트 간 통합이 발생한다.
다음과 같은 상황일 때 바운디드 컨텍스트 간 통합이 필요하다.
- 사용자가 제품 상세 페이지를 볼 때, 보고 있는 상품과 유사한 상품 목록을 하단에 보여준다.
사용자가 카탈로그 바운디드 컨텍스트에 추천 제품 목록을 요청하면 카탈로그 바운디드 컨텍스트는 추천 바운디드 컨텍스트로부터 추천 정보를 읽어와 추천 제품 목록을 제공한다.
카탈로그 시스템은 추천 시스템으로부터 추천 데이터를 받아오지만, 카탈로그 시스템에서는 카탈로그 도메인 모델을 사용해 추천 상품을 표현해야 한다.
다음과 같이 카탈로그의 모델을 기반으로 하는 도메인 서비스를 이용해 구현체는 인프라스트럭처 영역에 위치한다.
구현 클래스는 외부 시스템과의 연동을 처리하고 외부 시스템의 모델과 현재 도메인 모델 간의 변환을 책임진다.
두 모델 간의 변환 과정이 복잡하면 다음과 같이 별도의 클래스에서 처리해도 된다.
REST API를 호출하는 것은 두 바운디드 컨텍스트를 직접 통합하는 방식이다.
다음과 같이 메시지 큐를 이용해 간접적으로 통합하는 방법도 있다.
마이크로서비스는 작은 서비스로 나누어 개별 서비스를 독립된 프로세스로 실행하고 각 서비스나 REST API가 메시징을 이용해 통신하는 구조를 갖는다.
모델의 경계를 형성하는 바운디드 컨텍스트를 마이크로서비스로 구현하면 자연스럽게 컨텍스트별로 모델이 분리된다.
코드 수준에서 모델을 분리해 두 바운디드 컨텍스트의 모델이 섞이지 않도록 해준다.
-
바운디드 컨텍스트는 모델의 경계를 형성하기 때문에 경계 간 통합이 발생한다.
-
경계 간 통합이 발생할 때 REST API로 통신할 수도 있고 메시징 큐를 이용해 비동기로 통신할 수도 있다.
-
메시징 큐를 이용할 때 사용하는 데이터 구조는 어떤 바운디드 컨텍스트가 제공하는지에 따라 다르다.
-
만약 카탈로그 도메인에서 제공하면 pub/sub 모델을 따르게 된다.
-
반대로 추천 도메인에서 제공하면 비동기로 제공하는 것 외에 REST API와 다르지 않다.
바운디드 컨텍스트 간 관계는 다양하게 표현된다.
바운디드 컨텍스트 간 관계 중 가장 흔한 관계는 한 쪽에서 API를 제공하고 다른 한 쪽에서 그 API를 호출하는 관계다.
API를 사용하는 바운디드 컨텍스트는 API를 제공하는 바운디드 컨텍스트에 의존하게 된다.
하류 downstream 컴포넌트인 카탈라고 컨텍스트는 상류 upstream 컴포넌트인 추천 컨텍스트가 제공하는 데이터와 기능에 의존한다.
상류 컴포넌트는 일종의 서비스 공급자 역할을 하며 하류 컴포넌트는 그 서비스를 사용하는 고객 역할을 한다.
상류 컴포넌트는 하류 컴포넌트가 사용할 수 있는 통신 프로토콜을 정의하고 REST API나 프로토콜 버퍼를 이용해 서비스를 제공한다.
하류 컴포넌트가 다수 존재하면 상류 컴포넌트는 여러 요구사항을 수용할 수 있는 API를 만들고 이를 서비스 형태로 공개해 서비스 일관성을 유지하는 것을 공개 호스트 서비스 OHS Open Host Service라고 부른다.
상류 컴포넌트의 서비스는 상류 바운디드 컨텍스트의 도메인 모델을 따른다.
하류 컴포넌트는 외부 시스템의 도메인 모델이 내 도메인 모델을 침범하지 않도록 막아주는 **안티 코럽션 계층(ACL, Anti-Corruption Layer)**을 둔다.
이 계층에서 두 바운디드 컨텍스트 간의 모델 변환을 처리해 자신의 도메인 모델을 유지할 수 있다.
두 바운디드 컨텍스트가 같은 모델을 공유하는 경우 중복 설계를 막기 위해 사용하는 두 팀이 공유하는 모델을 **공유 커널(SK, Shared Kernel)**이라고 부른다.
하지만 두 팀이 한 모델을 공유하기 때문에 밀접한 관계를 유지해야한다.
**독립 방식 관계 (SW, Separate Way)**는 서로 통합하지 않는 방식이다.
두 바운디드 컨텍스트 간에 통합하지 않으므로 서로 독립적인 모델을 발전시킨다.
독립 방식에서 두 바운디드 컨텍스트 간의 통합은 수동으로 이루어진다.
컨텍스트 맵은 전체 시스템의 이해 수준을 보여준다.
개별 바운디드 컨텍스트에 매몰되면 전체를 보지 못할 때가 있다.
바운디드 컨텍스트 간의 관계를 표시해 전체 비즈니스를 조망할 수 있도록 하는 것이 컨텍스트 맵이다.
바운디드 컨텍스트 영역에 주요 애그리거트를 함께 표시하면 모델에 대한 관계가 더 명확히 드러난다.