도메인 주도 설계 핵심 | Chap-04 컨텍스트 매핑과 전략적 설계

컨텍스트 매핑

• DDD에서 애자일 프로젝트 관리 핵심 도메인을 다른 바운디드 컨텍스트와 통합 하는 행위

• 서로 다른 두 바운디드 컨텍스트 안에 각각의 보편언어가 있는 것을 생각해보면, 이 선은 두 언어 사이의 통역을 나타낸다.
• 컨텍스트 매핑을 살펴볼 때, 2개의 바운디드 컨텍스트 사이에 놓여진 선이 어떤 종류의 팀들 사이에 존재하는 관계와 통합인지에 주목해야 한다.

매핑의 종류

파트너십

• 두 팀은 일련의 목표에 대한 의존성에 맞추기 위해 파트너십을 구성한다.
• 두 팀이 함께 성공하거나 다같이 실패한다는 의미다.
• 파트너십이 상호간 이점을 제공한다면 관계를 지속시키고, 서로의 의존성이 줄어들어 이점이 사라지는 상황이라면 다른 관계로 매핑을 설정해야 한다.

공유 커널

• 2개(또는 그이상) 팀 사이에 작지만 공통인 모델을 공유하는 관계
• 각 팀은 공유하는 모델 요소에 대해 서로 합의해야 한다.
• 관련된 모든 팀들이 각자 저마다의 길을 가는 것보다 공유 커널이 더 좋은 생각이라고 여긴다면 좋은 결과를 얻을 수 있다.

고객-공급자 (Downstream-Upstream)

• 공급자(Upstream) : 고객이 원하는 것을 제공해야 하고 관계를 주도하는 역할
• 고객(Downstream) : 다양한 기대를 충족시키기 위해 공급자와 함께 계획하는 역할
• 공급자가 고객의 실제적 요구를 무시하고 완전히 제멋대로인 상황만 아니라면, 이는 팀 사이에 매우 일반적이고 현실적인 관계이며, 같은 조직 내에서도 마찬가지로 적용된다.

준수자(Conformist)

• 상류 팀이 하류 팀의 특정 요구에 지원할 동기가 없는 경우에 나타난다.
• 현재의 상류팀 모델을 그대로 따른다. = 하류팀이 상류팀의 보편언어를 준수한다. => 준수자
  • 상류팀의 보편언어를 계속 변환시키는 것이 쉽지 않다.
• 확실하게 자리잡은 매우 거대하고 복잡한 모델과의 통합이 필요할 때 이런 유형이 나타난다.

반부패 계층(Anticorruption Layer)

• 가장 방어적인 컨텍스트 매핑 관계
• 상류 모델로부터 하류 모델을 독립시키고 둘 사이를 번역한다.
• 가능하다면 하류 모델과 상류 통합 모델 사이에 반부패 계층을 만들어야 한다.
  • 통합에 용이한 모델 개념, 원하는 형태의 특정 비즈니스 요구 맞추기 가능, 외부의 이질적인 개념으로부터 독립성 유지

공개 호스트 서비스(OHS, Open Host Service)

• 바운디드 컨텍스트를 통합하고자 하는 모두가 용이하게 사용할 수 있도록 공개 된 서비스
• 다른 종류의 시스템보다 사용하기 훨씬 쉽다.

공표된 언어

• 간단한 사용과 번역을 가능하게 하는 잘 문서화된 정보 교환 언어
• XML 스키마, JSON 스키마 또는 프로토버프나 아브로처럼 좀 더 최적화된 작성 형식으로 정의 가능

각자의 길 (Separate Ways)

• 다양한 보편언어를 사용하는 것이 무의미한 경우 사용

큰 진흙 덩어리

• 아래와 같은 문제 발생
  • 부적절한 연결과 의존으로 인해 문제를 확산시키는 애그리게잇 증가
  • 큰 진흙 덩어리의 일부를 관리할 때는 "두더지 잡기"처럼 한 가지 문제가 해결돼도 또 다른 문제를 계속 야기시킬 수 있음
  • 오직 전반적 지식과 모든 언어를 한 번에 다룰 수 있는 사람만이 시스템 작업 가능

컨텍스트 매핑 활용하기

• 견고함 정도(낮음->높음) : RPC, 레스트풀 HTTP, 메시징

SOAP을 이용한 RPC

• RPC(Remote Procedure Calls)의 잘 알려진 사용법 중 하나는 SOAP을 이용하는 방법이다.
• SOAP을 이용한 RPC는 다른 시스템이 서비스를 사용할 때 마치 단순히 로컬 프로시저나 메서드를 호출하는 것처럼 사용한다는 개념
• 첫 통합 수행 시점에 예기치 못한 네트워크 장애나 작게는 지연의 가능성을 동반할 수 있다.
  • 문제 발생시 에러 결과만 받은 채 완전히 실패
• SOAP을 이용한 RPC는 클라이언트 바운디드 컨텍스트와 서비스를 제공하는 바운디드 컨텍스트 사이의 강한 결합을 암시
• 클라이언트 바운디드 컨텍스트를 분리할 필요가 있다면, 반부패 계층을 정의할 것

레스트풀 HTTP

• REST 인터페이스를 제공하는 서비스 바운디드 컨텍스트는 공개 호스트 서비스와 공표된 언어를 제공해야 한다.
• 레스트풀 HTTP는 네트워크나 서비스 제공자의 장애 또는 예기치 않은 지연 등에 이유로 실패할 수 있다.
• 리소스가 클라이언트 주도의 유스케이스를 지원할 수 있도록 종합적으로 설계해야 한다.

메시징

• 발행 바운디드 컨텍스트에서 발행한 도메인 이벤트를 구독 바운디드 컨텍스트에서 구독하는
• 분절된 형태와의 일시적인 결합을 대부분 제거할 수 있다.
• 즉각적인 결과가 필수적이지 않을 때는 메시징을 이용해 좀 더 견고한 시스템을 구축하는 것도 좋은 선택
• 비동기 메시징 방식을 사용하면 열차 충돌을 막을 수 있다.
• 클라이언트 바운디드 컨텍스가 커맨드를 날릴 수도 있으며 결과의 형태는 발행 바운디드 컨텍스트에서 발행하는 이벤트와 동일
• 통합에 메시징을 사용하는 경우, 전체 솔루션의 품질은 사용한 메시징 메커니즘의 품질에 크게 좌우된다.
• 적어도 한 번의 전달은 메시징 메커니즘이 특정 메시지를 주기적으로 재전달하는 메시징 패턴이다.
  • 메시지는 여러 번 전달될 수 있다.
• 멱등 수신자는 수신자가 오퍼레이션을 수행하는 방식이며, 매번 동일한 결과가 되도록 만드는 방식이다.
• 항상 비동기 요청-응답 통신을 사용하기 때문에 어느 정도의 지연은 일반적이고 다양하다.

컨텍스트 매핑 사례

• 메시징 구독을 통해 이를 제공받은 다른 바운디드 컨텍스트들이 이 도메인 이벤트에 반응할 때, 구독 바운디드 컨텍스트 안에 이 정책에 상응하는 정책 컴포넌트를 만들 수 있다.
  • 모두 담는것 : 자율성이 핵심 요구사항인 경우
  • 다시 쿼리하는 것 : 너무 많은 것을 담아야 하는 경우라면 재쿼리를 고려할 것
  • 혼합 방식