IDDD 3장. 컨텍스트 맵

바운디드 컨텍스트 간 관계를 그리는 것으로써 해결책 공간에 초점을 맞추가 있다.

컨텍스트 맵이 필수적인 이유

그림 3.1 추상적 도메인의 컨텍스트 맵

[출처] https://www.safaribooksonline.com/library/view/implementing-domain-driven-design/9780133039900/ch03lev1sec1.html

• U = 업스트림
• D = 다운스트림

컨텍스트 맵은 상호 교류하는 시스템의 목록을 제공하고, 팀 내 의사소통의 촉매 역할을 한다.

프로젝트와 조직 관계

통합 패턴들

• 파트너십(Partnership) : 두 컨텐스트가 한 트랜젝션으로 묶임 - 2 phase commit?
• 공유 커널(Shared kernel) : 상호 의존하는 공유 모델을 관리 - 안티 패턴이라고 봄
• 고객-공급자(Customer-Supplier Development) : 업스트림(서버:공급자), 다운스트림(클라이언트:고객)로 단방향 의존 표현
• 순응주의자(Conformist) : 업스트림(서버) is King
• 부패 방지 계층(Anticorruption Layer) : 변환을 통해서 다운스트림 컨텍스트 내 순수함을 지킴 (Adapter + Translator)
• 오픈 호스트 서비스(Open Host Service) : REST/API, RPC, Socket
• 발행된 언어(Published Language) : Json, XML, Byte
• 분리된 방법(Seprate Ways) : 의존 없음
• 큰 진흙공(Big ball of mud) : 똥덩어리

세 가지 컨텍스트를 매핑하기

before

• 문제점 공간
• 분리된 핵심을 이용

after

• 해결책 공간

• 대부분 순응주의자를 많이 사용하는 것 같다.
• 상호 의존이 걸리는 partnership도 많은 것 같다.
• 개인적으로는 고객-공급자가 좋다.
• 일반적으로 핵심 도메인은 다운스트림이다.
• 업스트림에서 다운스트림으로 모델 복제는 Evil이다.

[출처] https://www.codeproject.com/Articles/1158628/Domain-Driven-Design-What-You-Need-to-Know-About-

• 통합 전에 ACL를 통해서 변활할 시 최소한의 속성만 있으면 된다.

식별자와 액세스 컨텍스트의 통합

• 중요한 것은 애자일 프로젝트 컨택스트에 식별자 도메인이 침투하지 못하게 하는 것

협업 컨텍스트와 통합

결과적 일관성이 중요하다. - 이벤트 기반 아키텍쳐

그렇다면 상태관리를 해야한다.

enum DiscussionAvailability {
    ADD_ON_NOT_ENABLED, NOT_REQUESTED, REQUESTED, READY;
}

@Value
class Discussion {
    DiscussionAvailiability availability;
    DiscussionDescriptor descriptor;
    ...
}

class Product extends Entity {
    private Discussion discussion;
    ...
}

• Product에서 Discussion을 사용할 시 READY인 경우에만 가능

• 협업.Calendar -> 프로젝트관리.Scheduling
• 협업.Forum -> 프로젝트관리.Discussion

마무리

• OHS, PL, ACL