Bounded Context

많은 Model이 사용되는 코드는 버그가 발생할 확률이 높고, 이해하기 힘들다. 이런 문제점을 개선하기 위해서 Team, Application, Database 등의 기준으로 Context를 정의하고, 해당되는 Model을 정의한다. 이 Context를 Bounded Context라고 부르며 이 Context안의 Model은 일관된 상태로 유지하고, 다른 Context의 이슈 때문에 영향을 받아서는 안된다.

** Bounded Context는 Module이 아니다.

-> Moudle도 일종의 경계를 제공할 수 있기 때문에 헷갈릴 수 있지만 둘은 서로 동기가 다른 패턴이다. Module은 단일 Model 내에 포함된 요소를 구성하는 데도 사용되며, 꼭 개별 Context에 의도를 전달하는 것은 아니다.

---

1. Context Map

   1. 프로젝트 관리와 소프트웨어 설계 영역 사이의 걸쳐 있는 개념이다.
   2. 다른 팀에 속한 사람들은 Context 간의 경계를 인식하지 못할 수 있다.
   3. 때문에 자신도 모르는 사이에 Context의 경계를 흐리게 하거나, 연결되는 방식을 복잡하게 바꿀 수 있다.
   4. Bounded Context의 명칭은 Ubiquitous Language로 표현되며, 각 Bounded Context의 관계를 표현한다.
   5. 모든 구성원이 동일한 방법으로 개념적 경계를 이해하도록 의사소통할 수 있다.

2. Shared Kernel

   1. 팀 간의 협력이 조율되지 않을 경우 중복 작업이 생기고, 같은 이름의 객체가 서로 다른 의미를 가질 수 있는 등 구조를 개선하는데 많은 시간을 소요하게 된다.
   2. 이런 상황을 개선하기 위하여 두 팀 같이 공유하는 Model의 부분집합을 명시한다.
   3. 공유하는 부분은 특별한 상태를 가지며, 다른 팀과 협의 없이 변경할 수 없다.

3. Customer-Supplier Development Team

   1. 몇 Bounded Context의 관계가 "Upstream -> Downstream" 같이 단방향의 관계를 가지는 상황이다. 이 때 변경에 대한 거부권이 Downstream을 담당하는 팀에 있거나, 변경 요청 절차가 복잡하다면 Upstream을 담당하는 팀에서 자유롭게 개발을 진행하는데 제한이 생기거나 Downstream팀의 시스템에 장애가 발생할 것을 두려워해서 개발 자체를 억제할 수 도 있다.
   2. "Upstream/Downstream" 두 팀 간에 "공급자/고객"의 관계를 확립한다.
   3. 요구사항에 대한 작업을 협상하고 이에 대한 예산을 책정해서 모든 이들이 일정과 약속을 이해할 수 있어야 한다.
   4. 자동화된 인수 테스트를 양 팀이 함께 개발한다.
   5. 인수 테스트를 Upstream의 테스트 스위트에 추가하여 Side Effect를 두려워하지 않고 개발할 수 있도록 한다.
   6. 이러한 개발은 양 팀이 같은 조직이거나, 서로 신뢰가 있어야 한다.

4. Anti Corruption Layer

   1. 다른 조직이거나, 서로 신뢰가 부족한 상태에서 서로 다른 Bounded Context를 연동할 경우 중간에 Anti Corruption이라는 격리 계층을 추가하여 다른 Bounded Context를 잘못 이해했을 때 발생할 수 있는 문제점들을 회피한다.
   2. 여러 시스템의 상호작용에 필요한 통신, 전송 메커니즘과 Facade, Adapter 패턴을 조합하여 Anti Corruption Layer를 만든다.
      

      

5. Saparate Ways

   1. Bounded Context의 통합이 너무 힘든 상황이거나 서로의 기능을 필요로 하지 않거나 통합으로 얻을 수 있는 이점이 없을 때 아무 관계를 맺지 않도록 선언하여 개발자들이 각 Bounded Context 안에서 특화된 해결책을 찾을 수 있도록 한다.
6. Open Host Service
   1. 하위 시스템 접근과 관련된 Protocol을 특정 Service로 정의하여 공개한다.
   2. Protocol은 단순하고 일관되어야 한다.
   3. Protocol을 개선하고 확장하되, 특정 팀에만 해당되는 요구사항은 제외한다.
   4. Published Language를 사용하여  Model 간 Dependency를 줄이고, 이해를 쉽게 할 수 있다.
7. Published Language
   1. XML, JSON 같이 Domain을 표현할 수 있는 문서화된 공유 언어를 공통의 의사소통 매개체로 사용한다.
8.