바운디드 컨텍스트 간 관계는 다양하게 표현된다.
바운디드 컨텍스트 간 관계 중 가장 흔한 관계는 한 쪽에서 API를 제공하고 다른 한 쪽에서 그 API를 호출하는 관계이다.
API를 사용하는 바운디드 컨텍스트는 API를 제공하는 바운디드 컨텍스트에 의존하게 된다.
하류(downstream) 컴포넌트인 카탈로그 컨텍스트는 상류(upstream) 컴포넌트인 추천 컨텍스트가 제공하는 데이터와 기능에 의존한다.
상류 컴포넌트는 일종의 서비스 공급자 역할을 하며 하류 컴포넌트는 그 서비스를 사용하는 고객 역할을 한다.
상류 컴포넌트는 하류 컴포넌트가 사용할 수 있는 통신 프로토콜을 정의하고 REST API나 프로토콜 버퍼(Protocol Buffers)를 이용해 서비스를 제공한다.
하류 컴포넌트가 다수 존재하면 상류 컴포넌트는 여러 요구사항을 수용할 수 있는 API를 만들고 이를 서비스 형태로 공개해 서비스의 일관성을 유지하는 것을 **공개 호스트 서비스(OHS, Open Host Service)**라고 부른다.
상류 컴포넌트의 서비스는 상류 바운디드 컨텍스트의 도메인 모델을 따른다.
하류 컴포넌트는 외부 시스템의 도메인 모델이 내 도메인 모델을 침범하지 않도록 막아주는 **안티코럽션 계층(ACL, Anti-Corruption Layer)**을 둔다.
이 계층에서 두 바운디드 컨텍스트 간의 모델 변환을 처리해 자신의 도메인 모델을 유지할 수 있다.
두 바운디드 컨텍스트가 같은 모델을 공유하는 경우 중복 설계를 막기 위해 사용하는 두 팀이 공유하는 모델을 **공유 커널(SK, Shared Kernel)**이라고 부른다.
하지만 두 팀이 한 모델을 공유하기 때문에 밀접한 관계를 유지해야 한다.
**독립 방식 관계(SW, Separate Way)**는 서로 통합하지 않는 방식이다.
두 바운디드 컨텍스트 간에 통합하지 않으므로 서로 독립적으로 모델을 발전시킨다.
독립 방식에서 두 바운디드 컨텍스트 간의 통합은 수동으로 이루어진다.
수동으로 통합하는 것이 나쁜 것은 아니지만 한계가 존재하기 때문에 두 바운디드 컨텍스트를 통합해주는 별도의 시스템을 만들 수도 있다.
대부분의 바운디드 컨텍스트 간 관계는 공개 호스트 서비스와 같이 상류 컴포넌트와 하류 컴포넌트로 이루어진다.
이때 자신의 도메인 모델에 영향을 끼치지 않도록 보호해 주는 안티코럽션 계층이 존재한다.
컨텍스트 간의 경계를 표현할 때 Published Language, Conformist, Partnership 등 다양한 방법으로 나타낼 수 있다.
바운디드 컨텍스트 간 관계를 잘 파악해 올바르게 정의하는 것이 중요하다고 생각한다.