DDD에는 전략적 설계와 전술적 설계라는 개념이 존재한다. 그 중 DDD 의 핵심이라고 말할 수 있는 전략적 설계에 대해 작성해본다.
(유튜브 영상 "[NHN FORWARD 22] DDD 뭣이 중헌디?" 와 "도메인 주도 설계로 시작하는 마이크로서비스 개발" 서적을 참고하였다. )
| 설계 | 전략적 설계 | 전술적 설계 |
| 범위 | 전반적 | 특성 바운더리 컨텍스트 |
| 목적 | 문제 도메인을 해결영역으로. | 풍부한 도메인 모델 적용 |
| 메타포 | 전쟁에서 전략 | 전투에서 전술 |
| 주요패턴 | 바운터리 컨텍스트, 유비쿼터스 언어, 애그리거트, 도메인 이벤트 | |
| 수행 방식 | 접근법 | 상대적으로 방법론에 가까움 |
DDD의 전략적 설계
비지니스 응집성을 고려하여 컨텍스트를 구분하고 나누어 설계한다.
컨텍스트는 어디서부터 시작이 되는 걸까?
비지니스 도메인에서 발생하는 상황들을 문제 도메인으로 추출하고, 해당 문제 도메인를 가지고 문제 공간을 만들어 문제 공간에서 정의된 것들을 해결 공간으로 바꾸는 과정이 전략적 설계의 큰 흐름이라고 할 수 있다.
비지니스 도메인 : 현실 세계
문제 도메인 : 소프트웨어 세계
라고 이해해도 좋다.
위 말을 풀어서 이야기하자면, 현실에서 우리가 고민하게 되는 비지니스 적인 문제들 중, 소프트웨어로 해결하고자 하는 것이 있다면 그것들을 문제 공간으로 추출하고, 소프트웨어에서 어떻게 해결할 수 있을지 고민하고 해결하는 과정이다.
이 과정에서 컨텍스트가 생기기 시작하는데, 컨텍스트를 추출하기 위해서는 우선 도메인 추출이 되어야한다.
그 전에, DDD에서 말하는 핵심 중에 하나인 유비쿼터스 언어를 집고 넘어가자.
유비쿼터스 언어 (Ubiquitous-Language) (도메인 언어)
유비쿼터스 언어 (도메인 언어) : 특정 도메인의 의도를 명확히 파악, 반영하고 도메인의 핵심 개념을 잘 전달할 수 있는 언어를 협업 구성원들이 약속하고 통용적으로 사용하는 언어.
이러한 유비쿼터스 언어를 사용하라고 말하고 있는데, 이 말은 즉, 각 개념들을 지칭하는 말들을 약속하여 모두 동일하게 사용하자는 뜻이다.
(ex. 서비스를 이용하는 유저 : "회원" 이라고 부르자.)
이런 유비쿼터스 언어를 조직에서 사용하여 커뮤니케이션하고 모델 정제를 지속할 수 있는 것이 DDD의 전략적 설계의 핵심이라고 할 수 있다.
도메인의 추출
도메인 전문가, 개발자 등등 해당 도메인을 담당하는 모든 조직원이 모여, 문제 도메인에서 여러개의 하위 도메인을 도출한다.(하위 도메인 : 서브 도메인)
서브 도메인을 도출했다면, 그것들을 가지고 서브 도메인의 성격을 구분한다.
서브 도메인은 세 가지로 구분할 수 있다.
- 핵심 서브도메인 : 차별화를 만들 비지니스 영역. 우선순위가 높다. 소프트웨어 개발에서 전략적으로 가장 큰 투자가 필요한 영역.
- 지원 서브도메인 : 핵심 서브도메인을 지원하기 때문에, 비지니스에 있어 필수적이지만 핵심은 아닌 영역.
- 일반 서브도에인 : 비지니스적으로 특화된 영역을 아니나, 전체 비지니스 솔루션에는 필요한 영역.
인터넷 예매라는 문제 도메인을 하위 도메인으로 분리한다. (하위 도메인 : 서브 도메인)
분리한 서브 도메인이 각각 어떤 성격의 도메인인지, 서브 도메인의 성격을 추출한다.
예시 상황에서는
예매 : 핵심 서브도메인
상품, 도면 : 지원 서브도메인
회원 : 일반 서브도메인
으로 구분하였다.
이렇게 서브 도메인까지 도출이 되었다면, 해결 공간으로 이동하여 직접적인 소프트웨어 해결 방안을 모색하기 시작한다.
해결 공간
바운디드 컨텍스트 (Bounded-Context)
해결공간에서 모델들 사이에 경계를 만들어주는 것.
(이곳에서도 역시 유비쿼터스 언어의 사용이 중요하다! - 바운디드(경계)가 달라지면 사용되는 유비쿼터스 언어도 달라질 수 있다. )
바운디드 컨텍스트를 활용하면, 작업 중 모호해질 수 있는 모델의 무결성을 지켜준다.
1. 동일한 언어로 되어있는 서로 다른 개념들이 존재할 경우
바운디드 컨텍스트를 사용하므로써 동일한 언어임에도 각각의 개념들의 의미가 명확해진다.
각각의 바운디드 컨텍스트 안에서 개념 모델의 의미가 명확해졌다.
2. 동일한 개념 모델이지만, 여러 곳에 의존해야할 경우
넓은 영역으로 하나의 모델이 의존하므로 해당 모델이 상당히 큰 복잡도를 지니게 된다.
각각의 바운더리 컨텍스트 안에서 필요한 만큼만 참조하여 모델의 복잡도가 줄어들었다.
모델은 소프트웨어나 컨텍스트 안에서 해결해야할 문제에 대해서만 알고 있으면 된다.
=> 이것이 바로 모델의 목적이라고 할 수 있다.
바운디드 컨텍스트 별 전술 설정
각 서브도메인이 가지는 성격에 맞게 바운디드 컨텍스트 별 전술을 설정할 수 있다.
역콘웨이의 전략
🌽 콘웨이의 법칙?
소프트웨어의 구조는 해당 소프트웨어를 개발하는 조직의 구조를 따라간다.
그렇다면 "역"콘웨이의 법칙이란?
-> 개발하는 조직의 구조를 소프트웨어의 구조에 맞추는 것.
위와 같은 상황이라면, 핵심 도메인이 되는 예매 바운디드 컨텍스트 쪽에 조직내의 실력자들을 배치하고, 비용을 투자한다.
중요도가 낮은 일반 도메인은 외부업체를 쓰거나 하는 방식으로 해당 작업에 대한 비용을 낮춘다.
컨텍스트 맵 (Context-Map)
바운디드 컨텍스트 사이의 매핑 다이어그램을 그린 것.
컨텍스트 맵 : https://silvers-dev-note.tistory.com/52 참고
DDD 에 대한 오해
- DDD는 MSA 와 직결된다?
모델을 쪼개는 그림이 유사하여 많이 결합해서 사용하는 것이지, MSA를 한다고 해서 무조건 DDD를 적용해야하는 것은 아니며, DDD라고 해서 무조건 MSA 를 구현하는 것은 아니다.
- DDD는 방법론이나 기술이나 구현 영역이다.
해당 발언들은 DDD의 전술적 설계에 국한된 표현으로 생각할 수 있다. 흔히 많은 개발자들이 DDD의 핵심인 전략적 설계는 잘 생각하지 않고 보다 개발,코딩과 근접한 전술적 설계만을 많이 생각하고 하는 표현들인데, 사실 DDD의 핵심은 전략적 설계이고 굳이 정하여 말한다면 방법론,기술 보단 추상적인 철학이나 접근법으로 바라보는 것이 좋다.
DDD는 결국 비지니스 소프트웨어를 수행하기 위한 철학인 것 같다. 단지 개발에만 국한되는 것이 아니라 일하는 방식, 협업, 조직 체계, 아키텍처 등등 모든것을 아우르고 소개하고 있으니 말이다.