- 변하지 않은 용어와 모순 없는 일관성(통일성)
기업 규모 프로젝트에서는 기업 도메인 전체를 다루는, 모순 없고 겹치지 않는 용어를 담는 하나의 모델을 가진다. 하지만 통일된 모델을 계속 유지하기 위해서는 많은 팀의 노력이 필요하다. 설계에 대한 지속적인 의논이 필요하기 때문이다.
이를 위한 해결 방법은 하나의 큰 모델이 아닌 여러 개의 모델로 분할하는 것이다.
- 모델들이 각각 지켜야 하는 계약을 준수한다면 잘 통합될 것이다.
- 각 모델들은 경계가 명확히 구분되어야 한다.
- 모델들 간의 관계는 정밀하게 맺어져야 한다.
하나의 큰 모델을 여러 개의 모델로 분할한다. 하나의 모델은 하나의 팀에 할당하기에 적합할 만큼 작아야 한다.
- 모델의 범위를 정하고
- 컨텍스트 간의 경계를 설정한 다음
- 모델이 통합된 상태를 유지한다.
- 모델은 컨텍스트가 하나씩 있다. 명시적으로 모델에 적용할 수 있는 컨텍스트를 정의해야 한다. (팀 조직의 관점의 용어로 경계를 설정해야 한다. 애플리케이션의 특정 부분으로 사용되거나 코드 기반이나 데이터베이스 스킴처럼 물리적으로 선언되는 것)
- 모델의 컨텍스트 : 모델 안에서 사용되는 용어들이 특정한 의미를 가지는 것을 보장할 수 있도록 적용되는 조건들의 집합
- 분할된 컨텍스트는 모델에 담길 논리적인 프레임을 제공한다.
- 코드는 일찍 통합될수록 좋다.
- 하나의 소규모 팀에서는 일일 단위의 통합을 권장
- 통합된 코드는 테스트할 수 있도록 자동으로 빌드되어야 한다.
- 테스트는 자동화되어야 한다.
- 통합하고, 빌드하고, 테스트하는 자동화된 절차를 통해 에러를 조기에 발견하고 고칠 수 있다
- 지속적인 통합은 분할된 컨텍스트에 적용된다. 이웃하는 컨텍스트 간의 관계를 다루자고 사용하는 것은 아니다.
모델은 초기부터 충분하게 정의될 수 없다. 모델은 생성되고 나면 개발 프로세스 동안 도메인에 대한 새로운 이해를 바탕으로 끊임없이 피드백을 받는다 => 새로운 개념이 모델에 추가되거나 새로운 구성 요소가 코드에 추가될 수 있음을 의미한다.
새로운 구성 요소가 기존 모델과 조화롭게 추가 적용되고, 코드로 올바르게 구현되도록 보장할 수 있는 통합된 프로세스가 필요하다.
- 서로 다른 분할된 컨텍스트들과 그들의 관계에 대한 개요를 표현한 문서
- 도메인 모델의 일부는 두 팀이 공유한다. 모델의 부분 뿐 아니라 관련된 코드 및 데이터베이스 설계의 일부도 포함된다.
- 공유 지점은 다른 팀과 협의하지 않고 변결해서는 안된다.
- 컨텍스트 간의 상호작용 수준이 높을 때 사용한다.
- 두 서브시스템 한 쪽이 다른 한 쪽에 완전히 의존하는 관계일 경우 의존하는 쪽이 고객, 공급해 주는 쪽이 공급자 역할을 한다.
- 두 서브시스템의 컨텍스트는 별도로 존재하고, 한 쪽의 처리 결과는 다른 쪽에 반영된다.
- 컨텍스트 간의 상호작용 수준이 높을 때 사용한다. 하지만 공유 커널은 없다.
- 두 서브시스템의 인터페이스는 정교하게 정의되어야 한다.
- 순응적 테스트 수트
- 인터페이스 요구사항이 준수될 때마다 언제든 테스트되어야 한다.
- 자동화된 인수 테스트 : 인터페이스가 예상대로 동작하는지 확인. 이 테스트는 공급자 팀의 테스트 수트에 추가해 지속적 통합의 일부가 되도록 유지한다.
- 서로 다른 도메인과 언어 간에 양방향 번역자의 역할을 한다.
- 장점은 클라이언트 모델이 외부로부터 영향 받는 오염 없이 순수하고 일관된 상태로 남는다는 점이다.
- 구현 : 변질 방지 레이어 = 서비스 (클라이언트 모델 관점)
- 서비스는 필요한 번역을 수행하고 모델은 외부와 독립된 채로 유지된다.
- 변질 방지 레이어는 서비스를 하나 이상 포함할 수 있다. 각각의 서비스에 대응되는 퍼사드가 존재하고, 각 퍼사드는 어댑터가 추가된다.
- Facade
- Adaper : 클래스와 인터페이스를 클라이언트가 이해할 수 있는 것으로 변환
- Translator : 객체와 데이터 변환
증류 : 혼합체를 구성하고 있는 물질을 분리해 내는 절차. 증류의 목적은 혼합체로부터 특별한 물질을 분리하는 것
도메인을 증류 처리할 때 생기는 부산물은 도메인의 다른 파트를 구성하는 일반 서브도메인이다.
- 핵심 도메인을 찾고 지원 모델이나 핵심 도메인을 쉽게 구분할 수 있는 수단을 제공한다.
- 핵심 도메인을 기준으로 사람을 채용하라(?)
- 프로젝트 근본 동기가 아닌 응집도 높은 서브도메인을 식별한다.
- 상용 솔루션
- 아웃소싱
- 기존 모델
- 사내(In-House) 개발
DDD는 도메인 이슈에 집중해야 한다는 원칙을 기반에 둔다.
- 단순한 상태를 유지하라. 모델러도 코드를 작성해야 한다.
- 구체적인 시나리오에 초점을 맞춘다. 추상적 생각은 실제 사례에 연결되어 있어야 한다.
- DDD를 모든 것에 적용하려고 하지 마라. 컨텍스트 맵을 그리고 어느 부분에 DDD를 적용하고 어느 부분에 하지 않을지 결정해야 한다. 그리고 그 경계 바깥에 있는 것들에 대해서는 신경 쓰지 않는다.
- 실험을 많이 하고 실수를 많이 할 것이라고 예상하라. 모델링은 창조적인 작업이다.