시작하면서
우리는 하나의 단어를 여러 의미로 사용하는 상황을 많이 마주했으며, 앞으로도 계속 사용될 예정이다.
비즈니스에서 Account라는 단어를 보면 은행에서는 계좌로 보지만, ERP 시스템에서는 계정으로 사용된다.
이렇듯 글자는 같지만 의미가 다른 걸 동음이의어라 부른다.
개발적인 측면에서 애플리케이션의 전체적인 구조를 보면 다양한 도메인에서 같은 용어가 많이 발생하는 걸 볼 수 있다.
용어의 중복이 많다보니 하나의 모델로 처리하려는 시도가 생길 수 있다.
하나의 모델이 다양한 도메인에서 사용된다면 Common이라는 공통모듈에 집어넣고 팀 내에서 이를 사용하라고 통보할지도 모른다.
과연 올바른 방법일까?
아니다, 상품이라도 고객이 바라보는 상품과 주문에서의 상품은 서로 다르다. (서로 관리되는 상태도 다르다)
더군다나 하나의 모델로 관리되려면 다양한 도메인에서 사용되는 모든 상태가 하나의 모델로 합쳐지고 각각 도메인마다 사용 안 되는 상태가 많이 생기게 될 것이다.
또한 모델의 사소한 변경이 관련된 도메인에 영향을 끼치게 된다.
이를 해결하려면 어떻게 해야할까?
모든 도메인에서 사용되는 하나의 모델이 아닌 각 도메인에 맞게 모델을 만들어야 한다.
BOUNDED CONTEXT
같은 용어라도 하위 도메인마다 의미가 다르고 같은 대상이라도 지칭하는 용어가 다를 수 있기 때문에 한 개의 모델로 모든 하위 도메인을 표현하려는 시도는 올바른 방법이 아니며 표현할 수도 없다.
하위 도메인마다 사용하는 용어가 다르기 때문에 올바른 도메인 모델을 개발하려면 하위 도메인마다 모델을 만들어야 한다.
모델은 특정한 컨텍스트(문맥)하에서 완전한 의미를 갖는데, 이렇게 구분되는 경계를 갖는 컨텍스트를 DDD에서 BOUNDED CONTEXT라고 한다.
* 참고 : 유비쿼터스 언어는 바운디드 컨텍스트 안에서 의미를 갖고 존재한다.
좋은 BOUNDED CONTEXT
하나의 BOUNDED CONTEXT는 하나의 팀에만 할당되어야 한다.
- 하나의 팀은 여러 개의 BOUNDED CONTEXT를 할당받을 수 있다.
- 둘 이상의 팀이 하나의 BOUNDED CONTEXT를 같이 관리하는 건 안티 패턴이다.
각각의 BOUNDED CONTEXT는 각각의 개발 환경을 가질 수 있다.
CONTEXT MAP
바운디드 컨텍스트가 담당하는 소프트웨어를 조금 떨어져서 본다면, 컨텍스트 맵은 더 멀리서 바라본다.
컨텍스트 맵은 상호 교류하는 시스템의 목록을 제공하고, 팀 내 의사소통의 촉매 역할을 한다.
그림은 단순하게 Name-A에서 Name-B로 흐른다고 보면 된다.
- U : Upstream
- D : Downstream
프로젝트와 조직 관계
이러한 컨텍스트를 보면, 팀 구성에 따라 시스템이 닮아가거나(콘웨이의 법칙)이나 역으로 시스템에 따라 팀이 닮아가는 걸(역콘웨이의 법칙)을 볼 수 있다.
- 파트너쉽 : 두 CONTEXT가 하나의 트랜잭션으로 묶여 있다.
- 공유 커널 : 상호 의존하는 공유 모델을 관리한다.
- 고객-공급제 : 업스트림(서버:공급자), 다운스트림(클라이언트:고객)로 단방향으로 의존한다.
- 순응주의가 : 업스트림(서버)이 모든 것을 제어한다.
- 오픈 호스트 서비스 : REST/API, RPC, Socket
- 분리된 방법 : 의존 없음
- 큰 진흙공 : 안티 패턴.
번외, DDD vs OOP
그렇다면 DDD와 OOP차이는 무엇일까?
- OOP는 상속이나 재활용성을 위해서 공통된 데이터를 공유하는 것을 중시한다.
- DDD는 도메인의 분리를 중시한다.
도메인 주도 설계에 대한 유튜브 영상에 다음과 같은 댓글을 볼 수 있다.
언급하셨다시피, DDD의 진정한 힘은 유비쿼터스언어와 바운디드 컨텍스트부터 시작합니다.
유비쿼터스 언어를 반영해야 전술적 설계가 의미가 있는 셈이죠.
OO 에 근간하지만 OO 원칙을 정면으로 위배하는 패턴도 몇 있어요.
예를 들어, ID를 이용해서 애그리거트 간 디커플링을 시킨다든지, Domain Service는 행동을 객체에서 의도적으로 분리시키는 패턴이 OO와는 다른 개념입니다.
Value 타입을 사용하는 것을 권장하는 등 저는 DDD의 전술적 설계가 순수 OO보다 더 적용하기 심플한 측면이 있다고 개인적으로 생각해요.
참고 자료
DDD 세레나데
'개발 & 방법론 > DDD' 카테고리의 다른 글
| 이벤트 스토밍(Event Storming) (0) | 2022.11.04 |
|---|---|
| 유비쿼터스 언어(UBIQUITOUS LANGUAGE) (0) | 2021.12.15 |
| 테스트를 통한 코드 보호 (0) | 2021.10.15 |
| 레거시 코드, 빈약한 도메인 모델(Anemic Domain Model) (0) | 2021.10.06 |
| 도메인 주도 설계(Domain Driven Design)란? (0) | 2021.10.05 |