• 제법 규모가 있는 신규 시스템에서 여러 팀이 동시에 일을 진행하는 프로젝트 예제

• 공동 사용 객체인 Charge(요금)에 속성의 이름 변경, 몇 가지 메서드와 연관관계를 추가하여 문제 발생

  → 모순점을 해결하지 않고 코드를 결합하여 신뢰할 수 없는 소프트웨어

• 단일화(unification): 각 용어가 모호하지 않고 모순되는 규칙이 없는 모델의 내적 일관성

• 우리에겐 모델의 주요 부분을 밀접하게 단일화하는 수단이 필요

• 대규모 시스템의 도메인 모델을 완전하게 단일화한다는 것은 타당하지 않거나 비용 대비 효과적이지 않을 것

• 단일한 모델 하에서 대규모 프로젝트에 속하는 소프트웨어 일체를 통합하려는 의욕적인 시도는 지나친 과욕

• 하지만 다음과 같은 위험 요소

  1. 한번에 지나치게 많은 레거시를 교체하려 할지도 모른다.
  2. 대규모 프로젝트에서는 능력에 비해 조율에 드는 비용이 너무 커서 난관에 처할지도 모른다.
  3. 특화된 요구사항이 있는 애플리케이션에서는 요건을 완전하게 충족하지 못해 애플리케이션의 행위를 다른 곳에 둘 수 밖에 없는 모델을 사용해야 할 지도 모른다
  4. 이와 반대로 단일 모델로 모두를 만족시키려 해서 모델을 사용하기 어렵게 만드는 복잡한 대안으로 이어질지도 모른다.

• 다른 여러 모델 간의 경계와 관계를 표시해줄 수단이 필요

• CONTEXT MAP(컨텍스트 맵)

  • 프로젝트의 컨텍스트와 각 컨텍스트 간의 관계의 전체적인 개관을 제공

• BOUNDED CONTEXT

  • 각 모델의 적용가능성의 범위를 정의

• 그림 14-1 모델 무결성 패턴에 대한 내비게이션 맵

  

BOUNDED CONTEXT(제한된 컨텍스트)

규모가 큰 프로젝트에서는 다수의 모델이 사용되기 마련이다. 
그러나 개별적인 모델을 기반으로 작성된 코드가 한데 섞이면 많은 버그가 발생하고 신뢰성이 떨어지며 
이해하기 힘든 소프트웨어가 만들어진다. 아울러 팀 구성원 간의 의사소통이 혼란스러워진다. 
종종 어떤 컨텍스트에서 어떤 모델을 사용해서는 안 되는지 불분명한 경우도 있다

• 모델 컨텍스트: 모델에서 사용된 용어를 특정한 의미로 의사소통하기 위한 조건의 집합

모델이 적용되는 컨텍스트를 명시적으로 정의하라. 
컨텍스트의 경계를 팀 조직, 애플리케이션의 특정 부분에서의 사용법, 코드 기반이나 데이터베이스 스키마와 같은 
물리적인 형태의 관점에서 명시적으로 설정하라. 이 경계 내에서는 모델을 엄격하게 일관된 상태로 유지하고 
경계 바깥의 이슈 때문에 초점이 흐려지거나 혼란스러워져서는 안된다.

• BOUNDED CONTEXT는 MODULE이 아니다

  

예제

예약 컨테스트

• 해운 회사에서 화물운송 예약에 사용할 신규 애플리케이션을 개발하는 내부 프로젝트