: 온라인 쇼핑 사이트에서 매충 증대를 위해 카탈로그 하위 도메인에 개인화 추천 알고리즘을 도입하기로 했다고 하자.
: 기존 카탈로그 시스템을 개발하던 팀과 별도로 추천 시스템을 담당하는 팀이 새로 생겨서 이 팀에서 주도적으로 추천 시스템을 만들기로 햇다.
: 이렇게 되면 카탈로그 하위 도메인에는 기존 카탈로그를 위한 바운디드 컨텍스트와 추천 기능을 위한 바운디드 컨텍스트가 생긴다.
: 두 팀이 관련된 바운디드 컨텍스트를 개발하면 자연스럽게 두 바운디드 컨텍스트 간 통합이 발생한다. 카탈로그와 추천 바운디드 컨텍스틑 간 통합이 필요한 기능 예시는 다음과 같다.
•
사용자가 제품 상세 페이지를 볼 때, 보고 있는 상품과 유사한 상품 목록을 하단에 보여준다.
: 사용자가 카탈로그 바운디드 컨텍스트에 추천 제품 목록을 요청하면 카탈로그 바운디드 컨텍스트는 추천 바운디드 컨텍스트로부터 추천 정보를 읽어와 추천 제품 목록을 제공한다.
: 이때 카탈로그 컨텍스트와 추천 컨텍스트의 도메인 모델은 서로 다르다. 카탈로그는 제품 중심으로 도메인 모델을 구현하지만 추천은 추천 연산을 위한 모델을 구현한다.
: 카탈로그 시스템은 추천 시스템으로부터 추천 데이터를 받아오지만 카탈로그 시스템에서는 추천의 도메인 모델을 사용하기보다는 카탈로그 도메인 모델을 사용해서 추천 상품을 표현해야 한다.
: 즉 카탈로그의 모델을 기반으로하는 도메인 서비스를 이용해서 상품 추천 기능을 표현해야 한다.
: 도메인 서비스를 구현한 클래스는 인프라스트럭처 영역에 위치한다. 이 클래스는 외부 시스템과의 연동을 처리하고 외부 시스템의 모델과 현재 도메인 모델 간의 변환을 책임진다.
: 외부 추천 시스템이 제공하는 REST API를 통해서 특정 상품을 위한 추천 상품 목록을 받아온다.
: 이 REST API가 제공하는 데이터는 추천 시스템의 모델을 기반으로 하고 있기 때문에 API 응답은 카탈로그 도메인 모델과 일치하지 않는 데이터를 제공한다.
: 이런 데이터를 현재 도메인에서 제공하는 모델에 맞게끔 변환하는 작업을 걸친 후, 사용하면 된다.
: REST API를 호출하는 것은 두 바운디드 컨텍스트를 직접 통합하는 방법으로 직접 통합하는 대신 간접적으로 통합하는 방법도 있다.
: 대표적인 간접 통합 방식이 메시지 큐를 사용하는 것으로, 추천 시스템은 사용자가 조회한 상품 이력, 구매 이력과 같은 사용자 활동 이력을 필요로 하는데 이 내역을 받을 떄 메시지 큐를 사용하면 된다.
: 카탈로그 바운디드 컨텍스트는 추천 시스템이 필요로 하는 사용자 활동 이력을 메시지 큐에 추가한다.
: 메시지 큐는 비동기로 메시지를 전달하기 때문에 카탈로그 바운디드 컨텍스트는 메시지를 큐에 추가한 뒤 추천 바운디드 컨텍스트가 메시지를 처리할 때까지 기다리지 않고 자신의 처리를 계속한다.
: 추천 바운디드 컨텍스트는 큐에서 이력 메시지를 읽어와 추천을 계산하는 데 사용할 것이다.
: 이것은 두 바운디드 컨텍스트가 사용할 메시지의 데이터 구조를 맞춰야 함을 의미한다. 각각의 바운디드 컨텍스트를 담당하는 팀은 서로 만나서 주고받을 데이터 형식에 대해 협의해야 한다.
: 메시지 시스템을 카탈로그 측에서 관리하고 있다면 큐에 담기는 메시지는 카탈로그 도메인을 따르는 데이터를 넣을 것이다.
: 어떤 도메인 관점에서 모델을 사용하느냐에 따라 두 바운디드 컨텍스트의 구현 코드가 달라지게 된다.
