이 포스트는 IDDD의 2장을 보고 작성합니다.

도메인과 서브도메인

도메인이라는 용어는 여러 의미를 가진다. 비즈니스 전체 도메인을 말할 수도 있고, 한 가지 핵심 부분이나 다른 분야일 수도 있다.

도메인 모델이란 용어를 볼 때 넓은 의미의 도메인이라는 관점에서 본다면 한 조직의 전체 비즈니스 도메인을 위한, 하나로 응집력 있게 모든 항목을 포함하는 모델을 만들어야겠다고 생각할 수도 있다. 그러나 조직의 전체 도메인은 여러 서브 도메인으로 이뤄져있다. DDD를 사용할 때의 모델은 바운디드 컨텍스트 안에 만들어진다. 도메인 모델의 개발은 전체 비즈니스 도메인에서 단 하나의 특정 분야에 집중할 수 있는 방법이다.

서브도메인과 바운디드 컨텍스트(컨텍스트 경계)의 활용

예시에서 모든 것이 서로 연결돼 다른 모든 것과 서로 의존성을 갖기 때문에, 여러 서브도메인으로 나눌 수도 있는 소프트웨어 도메인 모델을 굳이 구분짓지 않는다면 변화가 계속됨에 따라 훨씬 큰 부담을 지게 된ㄷ.

그리고 논리적으로 서브도메인을 분리시키는 전략적 설계를 사용함으로써, 복잡도를 어느 정도 낮출 수 있었다. 논리적 서브도메인 분리를 점선으로 표시했는데, 이는 어떻게든 명백하게 분리된 모델로 만들어야만 한다는 의미는 아니고, 적어도 해당되느ㅜㄴ 특정 소매업체 비즈니스 운영에 적용할 최소한의 분리 모델이 무엇인지 나타낸 것이다.

서브도메인이 항상 큰 크기와 기능을 가진 특별한 모델을 포함하는 건 아니다. 때론 서브도메인은 고유의 핵심 도메인의 일부가 아닌, 일련의 알고리즘과 같은 간단한 형태일 수 있다.

핵심 도메인은 비즈니스적으로 탁월해야 하고, 서브 도메인은 비즈니스 성공을 위해 중요하긴 하지만 꼭 탁월할 필요는 없다.

왜 전략적 설계가 필수적인가

대부분 엔티티와 값객체의 상세 내용에 초점을 맞추는데, 이는 더 큰 그림의 비전을 가린다. 핵심 개념을 범용 개념과 혼용했고, 두 가지 모델을 하나로 만들어버렸다.

모듈화는 DDD 모델링에 꼭 필요한 도구이긴 하지만 언어적 불일치를 해결해주진 않는다.

전략적 설계를 하지 않는다면 풍부한 유비쿼터스 언어를 제대로 소스 코드에 반영하지 못한 채 이를 은연중에 내포하고 있을뿐인 모델을 만들고 말 수도 있다. 전략적 설계를 하는 과정에서(경계를 짓는 과정에서라고 이해해도 될듯) 팀은 도메인, 서브도메인 뿐 아니라 바운디드 컨텍스트도 제대로 이해하게 된다.

현실의 도메인과 서브 도메인

도메인은 문제점 공간과 해결책 공간을 모두 갖고 있다.

1. 문제점 공간

문제점 공간은 핵심 도메인과 핵심 도메인이 사용하는 서브도메인의 조합이다. 현재의 비즈니스에서 문제점을 탐색하기 때문에 보통 프로젝트마다 문제점 공간의 서브도메인이 달라진다.

2. 해결책 공간

하나의 바운디드 컨텍스트이며 구체적 소프트웨어 모델의 집합이다.

서브도메인을 일대일로 바운디드 컨텍스트와 묶으련느 시도는 바람직한 목표다. 그러나 레거시 시스템 예제를 보면 서브도메인은 주로 바운디드 컨텍슨트와 중첩된다. 개념적으론 하나인 큰 바운디드 컨텍스트를 두 개 이상의 서브도메인이나 한 서브도메인의 일부인 여러 바운디드 컨텍스트로 나눌 수 있다.

내가 지금까지 이해한 바로는 문제점 공간이 어떻게보면 현실의 문제. 해결책 공간은 현실의 문제를 해결하기 위해 개념적으로 추상화한 공간이다.

예를 들어, 지리적 매핑 서비스는 문제점 공간에선 재고관리 서브도메인의 일부로 간주하지만, 해결책 공간에선 재고관리 컨텍스트가 아니다.

바운디드 컨텍스트 이해하기

바운디드 컨텍스트는 명시적 경계이고, 그 경계는 모델의 개념 안에 그 속성, 오퍼레이션과 함께 특별한 의미를 가지고 있기 때문에 생성된다.

어떤 프로젝트는 모든 것을 빠짐없이 포괄하는 모델을 생성하려 시도하는 함정에 빠지고, 어디서든 통용되는 유일한 의미를 가진 이름을 개념우ㅢ 개념에 대해 전체 조직이 모두 동의하는 결과를 목표로 삼느ㅓㄴ다. 여기에는 구멍이 있다.

첫째, 모든 이해관계자로부터 모든 개념이 하나의 순수하고 구분된 글로벌한 의미를 갖는 것에 대해 동의를 얻기란 거의 불가능하다. 일부 조직은 너무 커서 전체의 의미 있는 동의를 얻는 것은 둘째치고 모든 사람을 함께 모으는 것도 불가능하다. 그러므로 차이점이 존재한다는 사실을 직시하고 바운드디드 컨텍스트를 통해 차이점이 명확하며 잘 이해하고 있는 도메인 모델을 각각 기술해야 한다.

1. 출판사 예시

출판사는 라이프사이클마다 개별적인 바운디드 컨텍스트를 사용. 명시적 바운디드 컨텍스트를 활용하면 비즈니스적 요구를 정확히 반영하며 점진적으로 개선되는 소프트웨어를 주기적으로 배포할 수 있다.

2. 모델 그 이상을 위해

바운디드 컨텍스트는 도메인 모델만을 포함하진 않는다. 이는 시스템이나 애플리케이션, 혹은 비즈니스 서비스를 표시해주기도 한다.

3. 바운디드 컨텍스트의 크기

바운디드 컨텍스트는 완전한 유비쿼터스 언어를 표현하기 위해 필요한 크기만큼 커야한다. 만약 어떤 개념이 유비쿼터스 안에 들어있지 않다면, 애초에 모델에 들어오지 말아야 한다.

잘못된 크기의 바운디드 컨텍스트를 만들게 되는 이유는 무엇일까? 우리는 실수로 유비쿼터스 언어가 아니라 아키텍처적 영향을 기준으로 삼았을 수 있다. 언어적 경계 대신 기술적 경계를 긋도록 했을 수도 있다.

또 다른 함정은 가용한 개발자 리소스로 작업을 분배하기 위해 바운디드 컨텍스트로 나누는 문제다. 작업 분배를 위해 경계를 강화하는 것은 컨텍스트 모델링의 언어적 동기 측면에서 잘못된 선택이다. 기술적 리소스의 관리를 위해 허위 경계를 부여할 필요가 없다.

때론 모듈의 사용에 신중을 기함으로써 바운디드 컨텍스트의 미니어처를 만드는 문제를 피할 수 있다.

IDE를 사용할 때 하나의 바운디드 컨텍스트는 하나의 프로젝트 안에서 머문다. 자바를 사용할 경우 하나 이상의 jar 파일 안에 바운디드 컨텍스트를 넣게 된다. 느슨하게 결합된 도메인 모델의 각 부분을 버전에 따라 독립적으로 활용하기 위해 여러 jar 파일로 나눠 담을 수도 있다.

4. 샘플 컨텍스트

시스템에 중요하면서 크기가 큰 바운디드 컨텍스트가 있지만 그 모델 중 필수적인 부분이 다양한 지원 기능으로 인ㄹ해 가려졌다면 이를 분리된 핵심으로 잘라내야 한다.

이 장을 읽고 느낀 생각

기존에는 예를 들어 User 서비스, Chat 서비스, Blog 서비스 등 최대한 고수준으로 추상화하여, 여러 비즈니스 영역에서 범용적으로 쓸 수 있는 컴포넌트를 만들려고 했다. 근데 이거는 문제점 공간에 초점을 맞춘 느낌이다. 물론 문제점 공간에 초점을 맞추긴 해야겠지만, 그걸 해결하기 위해 바운디드 컨텍스트를 쓰는 순간, 그 바운디드 컨텍스트는 다른 컨텍스트에서는 쓰기 어렵게 될 것이다. 따라서 바운디드 컨텍스트로 경계를 명시하고나면 보편적으로 쓸 수는 없다는 트레이드오프가 생길 것 같다.