DDD

DDD Distilled 반버논

. DDD

무엇?

DDD는 주로 바운디드 컨텍스트와 보편언어를 모델링하는 것에 대한 것.

왜?

비즈니스 모델의 복잡도가 높기 때문이다. 프로젝트의 기술적 측면보다 비즈니스 모델이 더 복잡하기 때문에 DDD를 사용하는 것.

어떻게?

개발자와 도메인 전문가가 함께 비즈니스 모델을 파고 들어야한다. 

전략적 도구로 바운디드 컨텍스트와 보편언어를 사용한다. 

서로 협업하여 나오는 거듭된 피드백에 의해 보편언어가 나오고, 팀의 화합된 멘탈 모델을 만들 수 있다.

유지?

최고의 학습과 최고의 지식 획득은 매우 긴 시간에 걸쳐 일어나며, 심지어 '유지'라고 하는 기간에도 일어난다. 팀의 유지가 시작될 때, 혁신은 끝났다고 생각하는 것은 큰 착각.

핵심 도메인에 '유지 단계'라는 딱지를 붙이지 말 것. 중요도는 떨어질 지라도 해가 지나도 계속 성장해야한다. 

오랜 기간 지속적 노력을 이끌어 낼 수 없다면, 이 모델이 과연 지금 이 순간 정말로 전념해야하는 전략적 차별화 요소, 즉 '핵심 도메인'인가?라고 반문해 볼 것

. 바운디드 컨텍스트

핵심이 무엇인가? 전략적 계획의 핵심이 되는 모든 개념들을 밀접하게 유지하면서 포용하고 나머지는 제외. 남은 개념들은 보편언어가 된다.

모델링 시에는 문제 영역(Problem space)의 일부로 보이지만, 해결 영역(Solution space)으로 빠르게 전횐되고 소스코드로 반영된다.

 - 문제 영억 Problem space: 주요 목표, 제약 사항, 위험 사항을 고려해서 단계를 설계

 - 해결 영역 Solution space: 문제 영역의 논의가 핵심 도메인으로 바라보는 해결 방안을 구현하는 곳.

. 보편언어

. 핵심도메인

다른 조직과의 경정에 대한 차별화를 위해 개발. 때문에 최소한 하나의 주요 사업 부문. 조직이 모든 것에 뛰어날 수 없고, 그렇게 만드려고 해서도 안됨.

기업의 올바른 전략적 결정을 위해 무엇이 핵심 도메인이어야하고, 어떤 것을 제외시켜야 하는지 현명하게 선택해야한다.

핵심 도메인에 최적의 자원을 투여해서 적절하게 투자해야함.

. 서브도메인

`하나의 바운디드 컨텍스트-하나의 서브도메인`이 가장 이상적이다. 

세가지 유형으로 나눠짐

 - 핵심 도메인

    보편 언어를 신중하게 만들기 위한 전략적 투자 영역.

    주요 자원 할당, 잘 정의된 도메인 모델이 존재함.

    기업이 뛰어나야 하는 부분에 대한 경계.

    심층적 학습과 이해를 얻기위한 헌신, 실험, 협업이 필수적

 - 지원 서브 도메인

    이미 존재하는 제품으로 해결할 수 없는 맞춤 제작 개발이 필요한 모델링 영역. 

    아웃소싱을 고려해 볼 수 있음. 이것 없이 핵심도메인을 성공시킬 수 없기 때문에 중요함. 

 - 일반 서브 도메인

    기존 제품 구매를 통해 바로 충족 가능

.컨텍스트 매핑

핵심 도메인과 다른 바운디드 컨텍스트의 연결

종류

 - 파트너십: 각 팀은 하나의 바운디드 컨텍스트를 책임지고, 일련의 목표에 대한 의존성에 맞추기 위해 파트너십 구성. 두 팀이 함께 성공하거나 다 같이 실패한다. 계속 파트너십 관계를 유지하지 못할 수 있음.

 - 공유 커널: 공통 모델을 공유하는 관계. 한 팀에서 공유하는 모델의 코드, 빌드 관리 테스트 수행. 열린 의사소통, 지속적인 합의가 있어야하므로 처리, 관리가 어렵다.

 - 고객-공급자: 가장 일반적인 형태. 공급자와 고객이 함께 계획하지만, 언제 무엇을 줄지 결정하는 건 공금자.

 - 준수자: 상류/하류 팀이 있고 상류팀이 특정 요구에 맞춰 보편언어를 변환시키는게 쉽지 않아 하류팀이 상류팀 모델을 그대로 따른다. ex 아마존

 - 반부패 계층: 상류팀의 보편모델과 하류팀의 보편모델 사이에 번역 계층을 하류팀이 만드는 것. 통합에 용이하지만 비용이 높아질 수 있음

 - 공개 호스트 서비스: 바운디드 컨텍스트에 대한 접근을 제공하는 프로토콜이나 인터페이스를 정의하고, API로 공개되어 문서화가 잘 되어있다.

 - 공표된 언어: 잘 문서화된 정보 교환 언어. xml, json, protobuf, avro (이건 공개 호스트에 들억는 내용인듯?)

 - 각자의 길

~~~

큰 진흙 덩어리

혹시 연결해야한다면 반부패계층을 반드시 쓸 것.

 - 부적절한 연결과 의존으로 인해 문제를 확산시키는 애그리게잇이 증가한다

 - 큰 진흙 덩어리의 일부를 관리할 때는 한 가지 문제가 해결돼도 또 다른 문제를 계속 야기시킬 수 있다.

 - 오직 전반적 지식과 모든 언어를 한번에 다룰 수 있는 영웅 같은 사람이 있어야 시스템을 완전한 붕괴로부터 지킬 수 있다.

~~~

. 애그리게잇

트래잭션의 일관성을 만드는 경계. 일관성과 성공을 보장하도록 애그리게잇 구성 요소를 설계해야한다.

경험 법칙?

설계의 네가지 기본 규칙

 1. 애그리게잇 경계 내에서 비즈니스 불변사항들을 보호하라

 2. 작은 에그리게잇을 설계하라

 3. 오직ID를 통해 다른 애그리게잇을 참고하라

 4. 결과적 일관성을 사용해 다른 애그리게잇을 갱신하라(아마도 멱등성?)

+ SRP 단일 책임 원칙 

올바른 크기의 애그리게잇

 - 하나가 변경될때 같이 변경되어야 하는 것이 있는지..

 - 애그리게잇의 행위에 관련된 모든 갱신에 걸리는 시각을 파악할 수 있는 관련된 각 애그리게잇의 목록과 일관성 규칙을 만든다.

 - 반응에 맞춘 갱신이 일어나는 시간은 얼마나 걸릴지. a. 즉시 b. n초/분/시간/일 (올바른 비즈니스 임계치를 찾는 한가지 가능한 방법은 받아들여질 수 없는 과장된 소유시간, 몆 주 혹은 몇 달)을 먼저 제시함. 비즈니스 전문가로 하여금 받아들일 수 있는 소요시간을 답하게 만들 수 있을 것ㅋㅋ)

 - 각각의 애그리게잇들이 즉시 처리돼야 할 경우, 동일한 애그리게잇 경계 안에 2개의 엔터티를 구성하는 것을 긍정적으록 검토해야한다.

.도메인 이벤트

주로 사례연구로 설명하고 있다. 네이밍, 프로퍼티 정의 등. 실제 구현 시 다시 읽어보면 좋을듯?

이벤트 소싱. (이벤트 소싱, cqrs 등의 방법으로 어그리게잇을 구성하고 해결하는걸 추천하고 있는듯)

성능 고려하기. 캐싱과 스냅샷 고려.