도메인 주도 설계 구현
도메인, 서브도메인, 바운디드 컨텍스트
바운디드 컨텍스트 이해하기
바운디드 컨텍스트는 그 안에 도메인 모델이 존재하는 명시적인 경계
명시적으로 다른 두 모델 내부에선 같거나 비슷한 이름의 객체임에도 서로 다른의미를 갖는 경우가 종종 있다.
두 모델을 명시적인 경계로 둘러싸면 각 컨텍스트 안의 각 개념이 나타내는 의미가 확실해진다.
어떤 프로젝트는 모든 것을 빠짐없이 포괄하는 모델을 생성하려 시도하는 함정에 빠지며
어디서든 통용되는 유일한 의미를 가진 이름의 개념에 대해 전체 조직이 모두 동의하는 결과를 목표로 삼는다.
이러한 모델링 접근법에는 구멍이 있다.
- 모든 이해관계자로 부터 모든 개념이 하나의 순수하고 구분된 글로벌한 의미를 갖는것에 대해 동의를 얻기는 불가능하다.
컨텍스트가 왕이다. 특히 DDD를 구현할 때는 컨텍스트가 왕이다. 컨텍스트는 문화적이기도 하다.
통합이 필요할 순간이라면 바운디드 컨텍스트들 사이의 매핑이 반드시 필요하다. 이는 DDD의 목잡도가 높게 나타나는 측면이며
그에 상당하는 관리 노력이 필요하다.
모델 그 이상을 위해
바운디드 컨텍스트는 도메인 모델만을 포함하진 않는다. 모델이 개념적 그릇을 채우는 주요 요소임은 사실이다.
모델이 영속성 데이터베이스 스키마의 생성을 주도할 때 데이터베이스 스키마는 경계의 안쪽에 위치한다.
이는 모델링 팀이 설계를 하고 개발해서 유지하기 때문에 그렇다.
반대로 데이터베이스 스키마가 이미 존재하거나 데이터 베이스 모델러로 만들어진 별도의 팀이 데이터베이스 스키마의 설계에 반대한다면
스키마는 도메인 모델이 차지한 바운디드 컨텍스트 안쪽에 머무르지 못한다.
바운디드 컨텍스트의 크기
DDD를 사용한 도메인 모델의 주요 구성 요소인 모듈, 애그리게잇, 이벤트, 서비스는 하나의 바운디드 컨텍스트에 어느정도의 수가 포함돼야 할까?
이는 줄 하나의 길이는 얼마나 되나요? 라고 묻는 것과 다를 바가 없다.
바운디드 컨텍스트는 완전한 유비쿼터스 언어를 표현하기 위해 필요한 크기만큼 커야한다.
진정한 핵심 도메인의 일부가 아닌 외부 개념은 제외돼야 한다. 진짜 핵심 도메인에 속하는 개념을 실수로 제거해버리지 않도록 조심하자
컨텟스트 맵 같은 도구들이 여러분의 팀이 좋은 판단력을 갖도록 도와줄 것이다.
우리가 주어진 바운디드 컨텍스트를 너무 엄격히 제한하면 필수적임에도 빠져버린 컨텍스트 개념으로 인해 구멍이 생긴다.
잘못된 바운디드 컨텍스트를 설정하는 이유는 무엇일까? 우리는 실수로 유비쿼터스 언어가 아닌 아키텍처적 영향을 기준으로 삼았을수도 있다.
또 다른 함정은 가용한 개발자 리소스로 작업을 분배하기 위해 바운디드 컨텍스트를 나누는 문제이다.
기술리더와 프로젝트 관리자는 개발자가 더작은 분량을 관리하는 일이 더 쉬운 것이라고 생각할 수 있다.