: 바운디드 컨텍스트 간에는 어떤 식으로든 연결이 되기 때문에 두 바운디드 컨텍스트는 다양한 방식으로 관계를 맺는다.
: 두 바운디드 컨텍스트 간 관계 중 가장 흔한 관계는 한쪽에서 API를 제공하고 다른 한 쪽에서 그 API를 호출하는 관계이다.
: REST API가 대표적으로 이 관계에서 API를 사용하는 바운디드 컨텍스트는 API를 제공하는 바운디드 컨텍스트에 의존하게 된다.
: 하류 컴포넌트인 카탈로그 컨텍스트는 상류 컴포넌트인 추천 컨텍스트가 제공하는 데이터와 기능에 의존한다.
: 상류 컴포넌트는 일종의 서비스 공급자 역할을 하며, 하류 컴포넌트는 그 서비스를 사용하는 고객 역할을 한다.
: 상류 컴포넌트는 보통 하류 컴포넌트가 사용할 수 있는 통신 프로토콜을 정의하고 이를 공개한다.
•
상류 팀은 여러 하류 팀의 요구사항을 수용할 수 있는 API를 만들고 이를 서비스 형태로 공개해서 서비스의 일관성을 유지할 수 있는데, 이때의 서비스를 공개 호스트 서비스라고 한다.
: 공개 호스트 서비스의 대표적인 예가 검색이다.
: 상류 커포넌트의 서비스는 상류 바운디드 컨텍스트의 도메인 모델을 따른다.
: 때로는 두 바운디드 컨텍스트가 같은 모델을 공유하는 경우도 있다.
: 공유 커널의 장점은 중복을 줄여준다.
: 마지막 관계는 독립 방식 관계입니다.
•
이는 서로 통합하지 않는 방식입니다.
•
독립 방식에서는 두 바운디드 컨텍스트 간의 통합은 수동으로 이루어진다.
•
수동으로 통합하는 방식이 나쁜 것은 아니나, 규모가 커질수록 수동 통합에는 한계가 있으므로 이를 통합해야한다.
