고객 / 공급자 관계를 갖는 BOUNDED CONTEXT

• 두 BOUNDED CONTEXT간 관계 중 가장 흔한 관계는 한쪽에서 API를 제공하고 다른 한쪽에서는 그 API를 호출하는 관계이다.
• 이 관계에서 API를 사용하는 BOUNDED CONTEXT는 API를 제공하는 BOUNDED CONTEXT에 의존하게 된다.

• 만약 상류 API에 변경이 생긴다면 하류 BOUNDED CONTEXT에서 오류가 발생할 수 있다.
• 그래서 항상 두 팀은 개발 계획을 서로 공유하고 일정을 협의해서 결정해야 한다.
• 이러한 문제를 조금이나마 해결하고자 상류팀은 하류팀의 요구사항을 수용할 수 있는 API를 만들고 이를 서비스 형태로 공개해서 서비스의 일관성을 유지할 수 있다.
• 이러한 서비스를 공개 호스트 서비스(OPEN HOST SERVICE)라고 한다.

공개 호스트 서비스(OPEN HOST SERVICE)

• 공개 호스트 서비스의 대표적인 예는 검색이다.
• 블로그, 카페, 게시판과 같은 서비스를 제공하는 포탈은 각 서비스 별로 검색 기능을 구현하기 보다 검색을 위한 전용 시스템을 구축하고 검색 시스템과 각 서비스를 통합한다.
• 이때 상류 컴포넌트는 검색 시스템이고, 하류 컴포넌트는 블로그, 카페, 게시판이 된다.
• 상류 컴포넌트의 서비스는 상류 BOUNDED CONTEXT의 도메인 모델을 따르기 때문에 하류 컴포넌트 모델에 영향을 주지 않도록 보호해 주는 완충 지대를 구축해야 한다.
• 이 완충 지대를 안티코럽션 계층(Anticoruption Layer)이라고 부른다.

공유 커널(SHARED KERNEL)

• 두 BOUNDED CONTEXT가 같은 모델을 공유하는 경우도 있다.
• 같은 서비스를 구축하는 두 팀에서 해당 서비스 모델을 공유함으로써 공통된 개발을 막을 수 있다.