관련된 바운디드 컨텍스트를 REST API나 메시징을 통해 통합할 수 있다.
카탈로그 하위 도메인에 개인화 추천 기능을 도입해 기존 카탈로그를 위한 바운디드 컨텍스트와 추천 기능을 위한 바운디드 컨텍스트가 있다.
두 팀이 관련된 바운디드 컨텍스트를 개발하면 자연스럽게 두 바운디드 컨텍스트 간 통합이 발생한다.
다음과 같은 상황일 때 바운디드 컨텍스트 간 통합이 필요하다.
- 사용자가 제품 상세 페이지를 볼 때, 보고 있는 상품과 유사한 상품 목록을 하단에 보여준다.
사용자가 카탈로그 바운디드 컨텍스트에 추천 제품 목록을 요청하면 카탈로그 바운디드 컨텍스트는 추천 바운디드 컨텍스트로부터 추천 정보를 읽어와 추천 제품 목록을 제공한다.
카탈로그 시스템은 추천 시스템으로부터 추천 데이터를 받아오지만, 카탈로그 시스템에서는 카탈로그 도메인 모델을 사용해 추천 상품을 표현해야 한다.
다음과 같이 카탈로그의 모델을 기반으로 하는 도메인 서비스를 이용하고 구현체는 인프라스트럭처 영역에 위치한다.
구현 클래스는 외부 시스템과의 연동을 처리하고 외부 시스템의 모델과 현재 도메인 모델 간의 변환을 책임진다.
두 모델 간의 변환 과정이 복잡하면 다음과 같이 별도의 클래스에서 처리해도 된다.
REST API를 호출하는 것은 두 바운디드 컨텍스트를 직접 통합하는 방법이다.
다음과 같이 메시지 큐를 이용해 간접적으로 통합하는 방법도 있다.
마이크로 서비스는 작은 서비스로 나누어 개별 서비스를 독립된 프로세스로 실행하고 각 서비스가 REST API나 메시징을 이용해 통신하는 구조를 갖는다.
모델의 경계를 형성하는 바운디드 컨텍스트를 마이크로서비스로 구현하면 자연스럽게 컨텍스트별로 모델이 분리된다.
코드 수준에서 모델을 분리하여 두 바운디드 컨텍스트의 모델이 섞이지 않도록 해준다.
바운디드 컨텍스트는 모델의 경계를 형성하기 때문에 경계 간 통합이 발생한다.
경계 간 통합이 발생할 때 REST API로 통신할 수도 있고 메시징 큐를 이용해 비동기로 통신할 수도 있다.
메시징 큐를 이용할 때 사용하는 데이터 구조는 어떤 바운디드 컨텍스트가 제공하는지에 따라 다르다.
만약 카탈로그 도메인에서 제공하면 pub/sub 모델을 따르게 된다.
반대로 추천 도메인에서 제공하면 비동기로 제공하는 것 외에 REST API와 다르지 않다.