각 바운디드 컨텍스트는 독립적이며 바운디드 컨텍스트의 크기는 때에 따라 다르다.
같은 비즈니스 도메인에서도 도메인 전문가마다 서로 다른 모델을 사용할 수 있다.
텔레마케팅 회사로 예를 들어본다면 회사의 마케팅 부서는 온라인 광고를 통해 리드를 생성한다.
영업 부서는 잠재고객이 제품이나 서비스를 구매하도록 유도하는 역할을 한다.
리드(lead)라는 용어가 마케팅 부서와 영업 부서에서 서로 다른 의미로 사용된다.
- 마케팅 부서 - 마케팅 담당자에게 리드는 누군가가 제품 중 하나에 관심이 있다는 알림을 나타낸다. 잠재고객의 연락처 정보를 수신하는 이벤트는 리드로 간주된다.
- 영업 부서 - 영업 부서 컨텍스트에서 리드는 영업 프로세스의 전체 수명주기를 나타낸다. 리드는 단순한 이벤트가 아니라 장기적으로 진행되는 과정이다.
다양한 비즈니스 도메인 모델을 사람들이 서로 상호작용하면서 정확한 의미를 추론하는 것은 쉽지만 소프트웨어로 표현하는 것은 어렵다.
소스코드는 모호성에 잘 대처하지 못하기 때문에 과도한 솔루션(over-engineered) 또는 더 필요한 솔루션(under-engineered)을 얻게 된다.
전통적인 해결 방안은 모든 종류의 문제에 사용할 수 있는 단일 모델을 설계하는 것이다.
이러한 모델은 항상 복잡성에 직면하게 된다.
또 다른 해결 방안으로 '마케팅 리드', '영업 리드'와 같이 문맥상 정의에 문제가 있는 용어 앞에 접두사를 추가하는 것이다.
하지만 이 방법은 각 모델을 언제 사용해야 하는지 인지부하를 유발하며 모델의 구현이 유비쿼터스 언어와 일치하지 않는다.
바운디드 컨텍스트는 유비쿼터스 언어의 일관성이 유지되는 경계다.
이런 시나리오를 다루기 위한 도메인 주도 설계 패턴 중 하나인 바운디드 컨텍스트를 해결할 수 있다.
유비쿼터스 언어를 여러 개의 작은 언어로 나눈 다음 각 언어를 적용할 수 있는 명시적인 **바운디드 컨텍스트(Bounded Context)**에 할당하면 된다.
각 바운디드 컨텍스트에서 단일 의미를 갖는 한, 세분화된 유비쿼터스 언어 각각은 일관성을 띠며 도메인 전문가의 멘탈 모델을 따를 수 있다.
용어 충돌과 암시적 컨텍스트는 적당한 규모의 모든 비즈니스에 내재된 부분이지만 바운디드 컨텍스트 패턴을 통해 명시적이고 중요한 비즈니스 도메인의 요소로 모델링할 수 있다.
우리가 해결하려는 문제는 실제 세계의 복사본이 아니라 모델 본연의 목적이다.
따라서 모델의 경계(바운디드 컨텍스트)를 정의하는 것은 모델링 프로세스의 본질적인 부분이다.
하나의 바운디드 컨텍스트의 유비쿼터스 언어는 다른 바운디드 컨텍스트의 범위에는 완전히 관련이 없다.
바운디드 컨텍스트는 유비쿼터스 언어와 해당 언어가 나타내는 모델의 적용 가능성을 규정하고 유비쿼터스 언어의 일관성이 유지되는 경계다.
유비쿼터스 언어는 조직 전체에서 '유비쿼터스'하게 사용하고 적용돼야 한다는 의미에서 '유비쿼터스'가 아니다.
모델은 우리가 해결해야 하는 문제 없이 존재할 수 없기 때문에 유비쿼터스 언어는 명시적으로 적용 가능한 컨텍스트 없이 정의하거나 사용할 수 없다.
유비쿼터스 언어의 일관성은 해당 언어의 가장 넓은 경계를 식별하는 데 도움이 될 뿐이다.
유비쿼터스 언어의 범위(바운디드 컨텍스트)를 정의하는 것은 전략적인 설계 의사결정이다.
경계는 비즈니스 도메인의 고유한 컨텍스트에 따라 넓힐 수 있고, 비즈니스 도메인을 더 작은 문제 도메인으로 세분화할 수도 있다.
모델의 크기에 정답은 없지만 모델 자체로 유용해야 한다.
바운디드 컨텍스트의 크기에 대한 결정은 문제 도메인이 무엇이냐에 따라 달라진다.
바운디드 컨텍스트의 크기를 비즈니스 요구사항과 조직의 제약사항에 맞추되, 응집된 기능을 여러 바운디드 컨텍스트로 분할하는 것을 주의해야 한다.
비효율적인 분해를 피하기 위해 응집된 유스케이스의 집합을 식별하되, 그것을 여러 바운디드 컨텍스트로 분해하지 말아야 한다.
비즈니스 전략을 이해하려면 비즈니스 도메인을 분석해야 한다.
도메인 주도 설계 방법론에는 따르면 분석 단계에서 다양한 하위 도메인을 식별하는 작업이 포함되는데 이는 경쟁 전략을 계획하는 방식이다.
하위 도메인은 비즈니스 도메인과 시스템 요구사항에 따라 정의되는 유스케이스 집합과 유사하다.
소프트웨어 엔지니어는 요구사항을 정의하는 것이 아니라 비즈니스 도메인을 분석한다.
모델의 경계를 선택하는 것은 전략적 설계의 의사결정이므로 바운디드 컨텍스트는 소프트웨어 엔지니어에 의해 설계된다.
소규모 시스템에서 단일 모델이 전체 비즈니스 도메인에 효과적으로 적용될 수 있다.
모델이 충돌하면 도메인 전문가의 멘탈 모델을 따라 시스템을 바운디드 컨텍스트로 분해할 수 있다.
또는 하위 도메인 경계에 맞춰 더 작은 바운디드 컨텍스트로 분해할 수도 있다.
중요한 것은 하위 도메인은 발견하고 바운디드 컨텍스트는 설계한다는 점이다.
하위 도메인은 비즈니스 전략에 의해 정의되고 소프트웨어 엔지니어는 컨텍스트와 제약 조건을 해결하기 위해 소프트웨어 솔루션과 바운디드 컨텍스트를 설계할 수 있다.
바운디드 컨텍스트 패턴은 물리적 경계와 소유권 경계를 규정하기 위한 도메인 주도 설계 도구다.
바운디드 컨텍스트는 모델 경계뿐만 아니라 이를 구현하는 시스템의 물리적 경계 역할도 한다.
각 바운디드 컨텍스트는 개별 서비스/프로젝트로 구현돼야 한다.
바운디드 컨텍스트 내에 여러 하위 도메인이 존재하는 경우 바운디드 컨텍스트는 물리적 경계고 하위 도메인은 논리적 경계다.
논리적 경계는 프로그래밍 언어의 종류에 따라 네임스페이스나 모듈, 패키지 같은 다른 이름을 갖는다.
팀 간의 작업 분배는 바운디드 컨텍스트 패턴을 사용하여 내릴 수 있는 또 다른 전략적 의사결정이다.
바운디드 컨텍스트는 한 팀에서만 구현, 발전, 유지 관리해야 한다.
서로 다른 바운디드 컨텍스트로 분리된 모델과 시스템을 명시적으로 연동하기 위한 통신 프로토콜을 정의해야 한다.
도메인 주도 설계의 바운디드 컨텍스트는 시맨틱 도메인의 사전적 개념에 기반한다.
**시맨틱 도메인(Semantic Domain)**은 의미 영역과 해당 의미를 전달하기 위해 사용하는 단어 영역으로 구분한다.
예를 들어 모니터, 포트, 프로세서라는 단어는 소프트웨어와 하드웨어 엔지니어링 시맨틱 도메인에서 서로 다른 의미를 갖는다.
모든 경우에 맞는 과학적 이론은 없고 다른 이론은 다른 맥락 안에서 유용하다.
두 모델이 모순되는 것처럼 보일 수 있지만 둘 다 적절한 (바운디드) 컨텍스트에서 유용하다.
모델은 실제 엔티티를 복사하는 것이 아닌 해결해야 할 문제가 있어야 한다.
"이 모델은 어떤 문제를 해결하고자 하는가?"라는 질문을 던져야 한다.
단순한 골판지 조각이 냉장고 모델이 될 수 있다.
골판지는 냉장고가 부엌을 통과할 수 있는지 확인한다.
또 냉장고가 부엌의 높이보다 낮은지 알 수 있는 방법은 줄자라는 또 다른 모델을 사용할 수 있다.
냉장고 모델을 직접 사용하는 것보다 다른 작은 모델로 나누어 쉽고 빠르게 해결할 수 있다.
모델은 당면한 작업과 관련 없는 정보는 생략해야 한다.
도메인 전문가의 멘탈 모델에 내재된 충돌을 발견할 때마다 유비쿼터스 언어를 여러 개 바운디드 컨텍스트로 분해해야 한다.
유비쿼터스 언어는 바운디드 컨텍스트의 범위 내에서 일관성이 있어야 하고 바운디드 컨텍스트는 한 팀에서 만들고 유지보수한다.
도메인을 바운디드 컨텍스트로 나누는 것은 전략적 설계의 의사결정이다.
바운디드 컨텍스트의 경계의 구분에 대해 알게되었다.
바운디드 컨텍스트의 경계는 반드시 하위 도메인의 경계와 일치하는 것이 아니고 바운디드 컨텍스트의 크기는 비즈니스 도메인에 따라 결정된다.
어떠한 비즈니스 도메인을 해결하기 위해 단일 모델을 사용할 수 있고 바운디드 컨텍스트를 나누어 서로 다른 모델을 사용할 수도 있다.
바운디드 컨텍스트는 모델, 소유권, 생명주기의 경계이다.
모델은 당면한 문제와 관련 없는 정보는 생략해 복잡성을 줄여야 한다.