도메인 주도 설계 구현
컨텍스트 맵
둘 이상의 기존 바운디드 컨텍스트들 사이의 매핑을 보여주는 단순한 다이어그램을 그리는 방법이다.
컨텍스트 맵이 필수적인 이유
DDD를 위한 노력을 처음 시작할때 현재 프로젝트 상황의 시각적 컨텍스트 맵을 먼저 그리자
컨텍스트 맵은 상호 교류해야 할 시스템의 목록 뿐 아니라 팀 내부의 의사소통에서도 촉매 역활을 한다.
컨텍스트 맵 그리기
컨텍스트 맵은 기존의 지형을 포착한다. 우선은 현재를 매핑해야 한다.
모든 그림과 글은 팀에 가치를 더할 수 있다면 하나의 참고 문서로 묶을 수 있다.
컨텍스트 맵은 엔터프라이즈 아키텍처나 시스템 다이어그램이 아니다.
다이어그램은 팀 공간의 벽에 붙여 볼만하다.
프로젝트와 조직의 관계
바운디드 컨텍스트와 개별적 프로젝트 팀 사이의 관계는 무엇인가? 몇몇의 DDD조직과 통합 패턴이 있으며, 하나의 패턴은 일반적으로 어떤 두 바운디드 컨텍스트를 뽑든 항상 그 사이에 존재하기 마련이다.
파트너쉽 : 두 가지 컨텍스트 안의 팀이 성공이나 실패를 함께한다면 협업 관계가 나타나야 한다.
공유 커널 : 모델에서 공유된 부분과 이에 관련된 코드는 아주 가까운 상호의존성을 형성하는데, 이는 설계 작업을 도울 수도 있고 약화시킬수도 있다. 커널은 작게 유지하고 명시적 경계로 지정하자.
고객-공급자 개발 : 두 팀이 업스트림과 다운스트림의 관계에 있고 업스트림 팀의 성공이 다운스트림 팀의 운영과 상호 의존적이라면 광범위한 결과를 초래할 다양한 방법으로 다운스트림 팀의 요구를 수용해야 한다.
순응주의자 : 업스트림 팀이 다운스트림 팀의 요구사항을 제공해줄 동기가 전혀 없는 업스트림/다운스트림 관계에서 다운스트림 팀은 속수무책의 상황에 빠진다.
다운스트림 팀은 맹목적으로 업스트림 모델을 준수해서 변환의 복잡성을 제거 한다.부패 방지 계층 : 변환 계층은 협조적인 팀 사이에서 잘 설계된 바운디드 컨텍스트를 연결할 때 간결하고 우아해질 수 있다.
오픈 호스트 서비스 : 여러분의 서브시스템에 접근할 수 있도록 해주는, 서비스 집합으로서의 프로토콜을 정의하자.
발행된 언어 : 두 바운디드 컨텍스트 모델 사이의 변환은 공통 언어를 필요로 한다.
분리된 방법 : 요구사항을 정의할 때는 무자비해야만 한다. 기능성 집합 사이에 유의미한 관계가 없다면, 이들을 서로 완전히 분리 해야 한다.
큰 진흙공 : 기존 시스템을 조사해 나가다 보면 여러 모델이 서로 뒤 섞이고 경계는 일정하지 않은 상황에서 시스템을 구성하는 부분들을 찾게 된다.
이런 어지러운 상황에 전체를 아우르는 경계를 진흙공으로 선언하자ACL : 부패 방지 계층(anticorruption layer)
OHS : 오픈 호스트 서비스(open host service)
PL : 발행된 언어(pubished language)