[도메인 주도 설계] 14. 모델의 무결성 유지 (2)

CONTEXT MAP (컨텍스트 맵)

• 서로 다른 CONTEXT를 연결하는 경우 CONTEXT는 서로에게 스며드는 경향이 있다.
• BOUNDED CONTEXT 간에 코드를 재사용하는 것은 피해야하며, 기능과 데이터는 번역 과정을 거쳐 통합해야 한다.
• 보통 컨텍스트의 경계는 팀 조직에 따라 정해지며, 물리적인 사무 공간 역시 컨텍스트 분리에 영향을 미칠 수 있다.
• 현재 진행중인 소프트웨어 모델과 설계의 개념적인 분할을 명확하게 바라볼 수 있도록 BOUNDED CONTEXT을 정의해야 한다.
• 경계가 모호한 모델을 발견했다고해서 전체적인 구조를 재구성하는 작업으로 이어져선 안된다. 분명한 CONTEXT MAP에 이르기까지는 명백하게 드러나는 모순만 변경한다.
  
  
• CONTEXT 경계에서의 테스트
  • 테스트는 컨텍스트의 경계에 존재하는 번역의 미묘한 차이와 낮은 수준의 의사소통을 보완하는 데 기여한다.
  • 통제할 수 없는 모델의 세부사항에 의존할 때 안심할 수 있게 만들어준다.
• CONTEXT MAP의 조직화와 문서화
  • BOUNDED CONTEXT의 이름은 해당 BOUNDED CONTEXT에 관해 이야기할 수 있는 것이어야 한다.
  • 모든 이들이 경계가 어디에 위치하는지 알아야하며, 어떠한 코드나 환경의 CONTEXT도 인식할 수 있어야 한다.

---

SHARED KERNEL (공유 커널)

• 공유커널의 목표는 중복을 줄이고 두 하위 시스템 간의 통합을 용이하게 만드는 것이다.
• 모델과 코드 기반 전체를 동기화하는 작업은 높은 비용이 들지만, 선택된 부분집합을 동기화하는 작업은 적은 비용으로 큰 이익을 얻을 수 있다.
• 두 팀 간에 공유하기로 한 도메인 모델 요소, 연관된 코드, 데이터베이스 설계의 부분집합을 명시한다.
• 명시적으로 공유하는 부분은 특별한 상태를 가지며, 다른팀과의 협의 없이는 변경할 수 없다.

---

CUSTOMER/SUPPLIER DEVELOPMENT TEAM (고객/공급자 개발 팀)

• 기본적으로 상류 컴포넌트와 하류 컴포넌트 간의 의존성은 단방향으로 흐른다.
• 하지만 변경에 대한 거부권이 하류 팀에 있거나 변경 요청 절차가 지나치게 복잡하다면 상류 팀의 개발이 하류 팀에 속박당할 여지가 있다.
• 하류 팀은 상류 팀에서 제공하는 것을 필요로 하지만 상류 팀은 하류 팀의 산출물에 대해서는 책임을 지지 않는다.
• 그러므로 두 팀간에 명확한 고객/공급자 관계를 확립한다. 하류 팀이 상류 팀에 대해 고객 역할을 맡아서 하류 요구사항에 대한 작업과 일정을 협의해야 한다.
• 인수 테스트를 추가해서 지속적인 통합의 일부로 실행한다. 상류 팀은 하류 팀에서 발생할지도 모르는 부수효과에서 자유로워질 수 있다.

---

CONFORMIST (준수자)

• CONFORMIST는 컴포넌트의 모델을 따르는 하위 모델을 의미한다.
• 상류/하류 관계에서 상류 팀이 하류 팀의 필요성을 충족시킬 충분한 동기를 느낄 수 없다면 하류 팀은 무력해진다.
• 상류 팀에서 제공하는 기능을 포기할 수 없다면, 상류팀의 모델을 준수해서 BOUNDED CONTEXT 간의 번역에 따른 복잡도를 제거할 수 있다.

---

ANTICORRUPTION LAYER (오류 방지 계층)

• 상호작용을 위해 새로운 시스템의 모델을 기존 모델과 유사하게 만들면 새로운 모델의 의도가 매몰될 수 있다.
• 저수준의 인터페이스를 사용하면 데이터를 표현하고 데이터의 값과 관계를 제약하는 모델의 힘이 사라진다.
• 또한 새로운 시스템의 모델에서는 사용하지 않는 용어를 사용해서 원시 데이터를 해석해야 한다.
• 그러므로 클라이언트 고유의 도메인 모델 측면에서 기능을 제공할 수 있는 격리 계층을 만들어서 두 모델을 상대로 양방향 번역을 수행한다.
• ANTICORRUPTION LAYER는 개념적인 객체와 행위를 하나의 모델과 프로토콜에서 다른 모델과 프로토콜로 변환하기 위한 메커니즘에 해당한다.
• ANTICORRUPTION LAYER의 인터페이스 설계
  • 보통 SERVICE의 집합으로 표현되며, 우리 모델 관점에서 응집력 있는 책임을 맡는 여러 개의 SERVICE(혹은 ENTITY)를 사용한다.
• ANTICORRUPTION LAYER의 구현
  • 여러 시스템 간의 상호작용에 필요한 통신 및 전송 메커니즘과 FACADE, ADEPTER, 번역기를 조합해서 ANTICORRUPTION LAYER의 설계를 구성할 수 있다.
  • FACADE는 하위 시스템에 대한 클라이언트의 접근을 단순화하고 쉽게 하위시스템을 사용할 수 있게 만들어주는 대안 인터페이스이다. 
  • ADAPTER는 행위를 구현하는 측에서 이해한 것과 다른 프로토콜을 클라이언트에서 사용하게 해주는 래퍼(wrapper)에 해당한다. 즉, 응답이 변환되어 재전송된다.
  • 번역기는 개념 객체나 데이터의 실제 변환을 담당한다.

 

 

---

SEPARATE WAYS (각자의 길)

• 요구사항을 철저하게 조사해서 두 기능 간의 관계가 필수적인 것이 아니라면 관계를 끊을 수도 있다.
• 통합의 혜택이 적다면 BOUNDED CONTEXT가 다른 것과 아무런 관계도 맺지 않도록 선언해서 범위 내에서 특화된 해결책을 찾을 수 있다.

---

OPEN HOST SERVICE (공개 호스트 서비스)

• 하위 시스템 접근과 관련된 프로토콜을 일련의 SERVICE로 정의하고 공개해서 통합을 원하는 모든 시스템에서 사용하도록 할 수 있다.
• 공유 프로토콜은 단순하고 일관되게 유지하며, 특수한 요구사항은 일회성 번역기로 처리한다.