[Domain Driven Design] Bounded Context

1. Bounded Context?

• 모델들의 경계 → 유비쿼터스 언어의 일관성이 유지되는 경계
• 유비쿼터스 언어를 여러 개의 작은 언어로 나눈 다음 명시적으로 할당함.
• 모델은 실제 세계의 복사본이 아닌 복잡한 시스템을 이해하는 데 도움을 주기 위해 구조화 한 것이다.
• 경계가 없다면 현실 세계의 복제본과 같이 확장될 것이다. → 모델의 경계(Bounded Context)를 정의하는 것은 모델링 프로세스의 본질적인 부분

2. Bounded Context의 범위

• 유비쿼터스 언어의 일관성은 해당 언어의 가장 넓은 경계를 식별하는데 도움이 될 뿐이다. → 일관성 없는 모델, 용어가 있기 때문에 더 이상 커질 수가 없다.
• 바운디드 컨텍스트 크기자체는 의사결정요소가 아님 → 모델의 크기에 정답이 없다.
• 경계가 넓을수록 일관성 유지 어려움, 경계가 많이 좁으면 설계하는데 오버헤드가 너무 큼 → 요구사항에 맞게 적절하게 나누자
  

3. Bounded Context vs Sub Domain(하위 도메인)

1. Sub Domain
   • 분석 단계에서는 다양한 하위 도메인(핵심, 지원, 일반)들을 식별하는 작업이 포함됨
   • 소프트웨어 엔지니어로서 요구사항을 정의하지 않는다. (비즈니스가 담당) → 엔지니어는 하위 도메인을 식별하기 위해 비즈니스 도메인을 분석한다.
     
2. Bounded Context
   • 소프트웨어 엔지니어에 의해 설계된다.
   • 모델의 경계를 선택하는 것은 전략적 설계의 의사결정이다.
3. 경계의 구성
   1. 물리적 경계
      • 시스템 물리적 경계역할
      • 각 바운디드 컨텍스트는 서비스/프로젝트로 구현되어야 한다. → 구현, 진화, 버전 관리를 각각 다른 바운디드 컨텍스트와 독립적으로 해야한다.
        
   2. 소유권 경계
      • 바운디드 컨텍스트는 한 팀에서만 구현, 발전, 유지 관리해야 한다.
      • 팀과 바운디드 컨텍스트 간의 관계는 단방향이다. → 바운디드 컨텍스트는 한 팀만 소유하되 여러 컨텍스트도 소유 가능하다.
        

4. 결론

• 도메인 전문가의 멘탈 보델에 내재된 충돌을 발견할 때마다 유비쿼터스 언어를 여러 개 바운디드 컨텍스트로 분해해야 한다.
• 유비쿼터스 언어는 바운디드 컨텍스트의 범위내에서 일관성을 유지해야 한다.
• 바운디드 컨텍스트는 시스템을 서비스, 하위 시스템 등의 물리적 구성요소로 분해한다. → 수명주기가 독립적