바운디드 컨텍스트 패턴은 유비쿼터스 언어의 일관성을 유지할 뿐만 아니라 모델링도 가능하게 함.

→ 모델의 목적, 즉 경계를 명시하지 않고는 모델을 구축할 수 없음.

→ 경계가 언어의 책임을 구분지음

→ 하나의 바운디드 컨텍스트 내의 언어는 특정 문제를 해결하는 비즈니스 도메인을 모델링함.

→ 다른 바운디드 컨텍스트가 동일한 비즈니스 엔티티를 대표할 수 있지만, 이는 다른 문제를 해결하는 비즈니스 도메인을 모델링함

한편 바운디드 컨텍스트의 모델은 서로 독립적으로 발전하고 구현될 수 있음. BUT 바운디드 컨텍스트 자체는 독립적이지 않음. 시스템의 요소가 독립적으로 구성될 수 없듯이, 다시 말해, 시스템의 요소가 전체의 목적을 이루기 위해 상호작용해야 하듯, 바운디드 컨텍스트의 구현도 마찬가지임

컨트랙트의 필요성은 바운디드 컨텍스트의 모델과 언어의 차이에서 비롯됨. 각 컨트랙트는 하나 이상의 당사자에 영향을 끼치므로 서로 조율해서 컨트랙트를 정의해야 함

이번 장에서는 바운디드 컨텍스트 간의 관계와 연동을 정의하는 도메인 주도 설계 패턴에 대해 배움.

→ 이런 패턴은 바운디드 컨텍스트에서 작업하는 팀 간의 협력적 특성에 의해 주도됨

→ 이런 패턴을 협력, 사용자-제공자, 그리고 분리형 노선의 세 그룹을 나눠 살펴봄

협력형 패턴 그룹


협력형 그룹의 패턴은 소통이 잘 되는 팀에서 구현된 바운디드 컨텍스트와 관련이 있음