도메인 모델은 특정 도메인을 개념적으로 표현한 것입니다. 이런 각 도메인 모델들은 특정한 Context에서 완전한 의미를 가집니다. 예를 들어 Account는 일반적인 관점에서는 계정이라는 뜻을 가지지만 은행에서는 계좌라는 뜻을 가집니다. 이렇듯, 일반적인 관점과 은행의 관점을 아예 다른 Context로 분리하여 도메인이 각 Context에서 유일하고 완전한 의미를 갖게 하는 경계들을 DDD에서는 바운디드 컨텍스트(Bounded Context)라고 칭합니다.

출처: https://happycloud-lee.tistory.com/94
바운디드 컨텍스트가 개념적인 도메인 모델만 포함하는 건 아닙니다. 바운디드 컨텍스트는 도메인 기능을 사용자에게 제공하는 데 필요한 Presentation, Application, Domain, Infrastructure, Database 등을 모두 포함합니다.
즉, 바운디드 컨텍스트는 개발적인 관점으로서도 그 책임과 기능을 명확히 분리하여 Loosely coupling & High cohesion를 만족하며 유지보수성을 높입니다.
바운디드 컨텍스트가 개념적으로도, 기능적으로도 분리되어 있기는 하지만, 서비스라는 더 상위의 도메인의 관점에서보면 이 바운디드 컨텍스트들 또한 서로 관계를 맺고 의존이 필요한 순간들이 옵니다.
그래서 서비스를 구축하면 바운디드 컨텍스트 간에 완벽히 분리되지는 못하고 통합이 필요합니다. 이 때 두 바운디드 컨텍스트간에 직접 통합 방식, 간접 통합 방식이 있습니다.

출처: https://devbksheen.tistory.com/entry/BOUNDED-CONTEXT-%EA%B0%84-%EA%B4%80%EA%B3%84

출처: https://devbksheen.tistory.com/entry/BOUNDED-CONTEXT-%EA%B0%84-%EA%B4%80%EA%B3%84
바운디드 컨텍스트 간에 가장 흔한 관계는 한 쪽에서 API를 제공하고, 한 쪽에서 그 API를 호출하는 관계입니다. 이 관계에서 API를 사용하는 컨텍스트는 API를 제공하는 컨텍스트에게 의존하게 됩니다.
이 때 다른 바운디드 컨텍스트서 재사용 할 수 있도록 공개된 인터페이스를 제공하는 서비스를 OHS(Open Host Service)라고 합니다.
OHS의 대표적인 예로는 검색이 있습니다. 블로그, 카페, 게시판과 같은 서비스를 제공하는 포탈은 각 서비스 별로 검색 기능을 구현하기 보다 검색을 위한 전용 서비스를 구축하고 이를 다른 서비스들과 통합합니다.
이 때 상위 컴포넌트는 서비스는 상위 바운디드 컨텍스트의 도메인 모델을 따르므로 하위 컴포넌트 모델에 영향을 주지 않기 위해 보호를 해주는 완충 지대를 구현해야 하고 이를 ACL(Anti-Corruption Layer)라고 합니다
두 컨텍스트가 같은 모델을 공유하는 경우도 있습니다. 같은 서비스를 구축하는 두 팀이 해당 서비스 모델을 공유함으로써 공통된 개발을 막을 수 있습니다. 이렇게 두 팀이 공유하는 모델을 공유 커널(Shared Kernal)이라고 합니다.
공통된 개발을 줄일 수 있다는 장점이 있지만, 임의로 모델을 변경해서는 안되며 두 팀이 밀접한 관련을 가지고 있어야 합니다.

컨텍스트 맵은 바운디드 컨텍스트간의 관계를 그림으로 표시한 것입니다. OHS, ACL을 표시하거나 하위 도메인이나 조직을 표시하면 도메인을 포함한 전체 관계를 이해하는데 도움이 됩니다. 컨텍스트 맵의 규칙은 따로 없고 각 컨텍스트의 관계를 이해하는데 초점을 둡니다.