9.4 바운디드 컨텍스트 간 통합
온라인 쇼핑 사이트에서 매출 증대를 위해 카탈로그 하위 도메인에 개인화 추천 기능을 도입하기로 했다고 하자. 기존 카탈로그 시스템을 개발하던 팀과 별도로 추천 시스템을 담당하는 팀이 새로 생겨서 이 팀에서 주도적으로 추천 시스템을 만들기로 했다.
=> 카탈로그 하위 도메인에는 기존 카탈로그를 위한 바운디드 컨텍스트와 추천 기능을 위한 바운디드 컨텍스트가 생긴다.
먼저 카탈로그에서 추천 상품을 보여주기 위해, 추천의 상품 모델을 사용하는 것이 아닌, 카탈로그 모델을 기반으로 하는 도메인 서비스를 이용해서 상품 추천 기능을 표현해야 한다.
외부 시스템의 데이터를 도메인에 맞게 변환
API 응답은 다음과 같이 카탈로그 도메인 모델과 일치하지 않는 데이터를 제공할 것이다.
[
{itemID: 'PROD-1000', type: 'PRODUCT', rank: 100},
{itemID: 'PROD-1001', type: 'PRODUCT', rank: 54}
]public class RecSystemClient implements ProductRecommendationService {
private ProductRepository productRepository;
@Override
public List<Product> getRecommendationOf(ProductId id) {
List<Recommendation> items = getRecItems(id.getValue());
return toProducts(items);
}
private List<RecommendationItem> getRecItems(String itemId) {
return externalRecClient.getRecs(itemId);
}
private List<Product> toProducts(List<RecommendationItem> items) {
return items.stream()
.map(item -> toProductId(item.getItemId()))
.map(prodId -> productRepository.findById(prodId))
.collect(toList());
}
private ProductId toProductId(String itemId) {
// 카탈로그 도메인의 Product 모델로 변환하는 작업을 처리.
return new ProductId(itemId);
}
}
두 모델 간의 변환 과정이 복잡하면 변환 처리를 위한 별도 클래스를
만들고 이 클래스에서 변환을 처리해도 된다.
바운디드 컨텍스트 간접적 통합: 메시지 큐
REST API 호출은 두 바운디드 컨텍스트를 직접 통합하는 방법이다.
간접적으로 통합하는 대표적인 방식은 메세지 큐를 사용하는것이다.
여기서 중요한건 카탈로그 시스템의 담당 팀과 추천 시스템 담당 팀이 협의해서 메시지의 데이터 구조를 맞춰야 한다는 점이다.
=> 메시지를 카탈로그 도메인 관점에서 관리하냐, 추천 도메인 관점에서 관리하느냐에 따라 메시지 구조도 달라진다.
- 물리적으로 분리된 각 바운디드 컨텍스트마다 REST API 혹은 메시지 큐로 통신하는 구조는 마이크로서비스에 적합한 구조이기도 하다.
9.5 바운디드 컨텍스트 간 관계
고객/공급자 관계
두 바운디드 컨텍스트 간 관계 중 가장 흔한 관계로 대표적인 예로 REST API가 있다.
=> 이 관계에서 API를 사용하는 쪽은 API를 제공하는 쪽에 의존하게 된다.
하류(downstream) 컴포넌트인 카탈로그 컨텍스트는 상류(upstream) 컴포넌트인 추천 컨텍스트가 제공하는 데이터와 기능에 의존한다.
- 상류가 바뀌게 되면 하류도 같이 바뀌게 된다.
- 따라서 상류 팀과 하류 팀은 개발 계획을 서로 공유하고 일정을 협의해야 한다.
공개 호스트 서비스(Open Host Service)
상류 팀은 여러 하류 팀의 요구사항을 수용할 수 있는 API를 만들고 이를 서비스 형태로 공개하는 것.
ex) 블로그, 카페, 게시판 서비스는 상류 공개 호스트 서비스인 검색 서비스를 의존한다.
상류 컴포넌트의 서비스는 상류 바운디드 컨텍스트의 도메인 모델을 따른다.
따라서 하류 컴포넌트는 자신의 모델에 영향을 주지 않도록 보호해 주는 완충 지대를 구축해야 한다.
이 완충 지대를 안티코럽션 계층(Anticorruption Layer) 이라고 부른다.
공유 커널(shared kernel)
두 바운디드 컨텍스트가 같은 모델을 공유하는 경우
하나의 모델을 두 바운디드 컨텍스트가 공유함으로써 중복 설계를 막을 수 있다.
=> 공통된 개발을 줄일수 있다는 장점이 있지만, 임의로 모델을 변경해서는 안되며 두 팀이 밀접한 관계를 유지해야한다.
독립 방식(Separate Way)
서로 통합하지 않는 방식
두 바운디드 컨텍스트간에 통합을 하지 않으므로 서로 독립적으로 모델을 발전시킨다.
독립 방식에서 두 바운디드 컨텍스트간에 통합은 사용자가 직접 수동으로 이루어진다.
수동으로 통합하는 방식이 나쁜 것은 아니지만 규모가 커질수록 한계가 있으므로
두 바운디드 컨텍스트를 통합해야한다.
9.6 컨텍스트 맵
개별 바운디드 컨텍스트에 매몰되면 전체를 보지 못할 때가 있다. 시스템의 전체구조를 봐야할때가 있는데 그것이 바로 컨텍스트 맵이다.
그림은 오픈 호스트 서비스(OHS)와 안티코럽션 계층(ACL)만 표시했는데, 하위 도메인이나 조직 구조를 함께 표시하면 전체 관계를 이해하는데 도움이 된다.
