[DDD] 2. 도메인 모델링

목차

1. 전략적 설계 - UBIQUITOUS LANGUAGE

2. 전략적 설계 - BOUNDED CONTEXT

3. 이벤트 스토밍(Event Storming)

 

 

 

 

1. 전략적 설계 - UBIQUITOUS LANGUAGE

유비쿼터스 언어(Ubiquitous Language)는 언제 어디서나 사용되는 언어란 뜻이다.

회의, 기획, 디자인, 개발 등 프로젝트 내부의 언제 어디서나 사용되기 위해 정의된 언어이다.

 

도메인에서 사용하는 용어를 프로젝트 내의 사람들이 모두 다르게 표현하면 번역 비용이 발생하고

코드에 사용된 언어와 다르거나 코드에 반영하지 않으면 그 코드는 개발자에게 코드의 의미를 해석해야 하는 부담을 준다.

따라서, 용어가 정의 될 때마다 용어 사전에 이를 기록하고 명확하게 정의 함으로써 추후 또는 다른 사람들도 공통된 언어를 사용할 수 있도록 한다.

코드의 가독성을 높여서 코드를 분석하고 이해하는 시간을 절약할 수 있고 사람들 사이에서 발생하는 번역 비용을 줄일 수 있다.

 

용어 사전

다음은 식당 포스기의 용어사전 예제이다. 참고

 

매장 주문

방문한 손님 수	number of guests	식기가 필요한 사람 수. 필수 사항은 아니며 주문은 0명으로 등록할 수 있다.
빈 테이블	empty table	주문을 등록할 수 없는 주문 테이블
서빙	served	조리가 완료되어 음식이 나갈 수 있는 단계
완료	completed	고객이 모든 식사를 마치고 결제를 완료한 단계
접수	accepted	주문을 받고 음식을 조리하는 단계
접수 대기	waiting	주문이 생성되어 매장으로 전달된 단계
주문	order	매장에서 식사하는 고객 대상. 손님들이 매장에서 먹을 수 있도록 조리된 음식을 가져다준다.
주문 상태	order status	주문이 생성되면 매장에서 주문을 접수하고 고객이 음식을 받기까지의 단계를 표시한다.
주문 테이블	order table	매장에서 주문이 발생하는 영역
주문 항목	order line item	주문에 속하는 수량이 있는 메뉴

 

도메인 모델링

용어 사전이 정의가 되었다면 용어 사전을 바탕으로 도메인을 모델링 한다.

표현해야 할 것을 더 쉽게 말하는 방법을 찾아낸 다음 그러한 새로운 아이디어를 다이어그램과 코드에 적용한다.

지속적으로 도메인을 탐색하며 풍부한 도메인 모델을 작성하도록 한다.

도메인 모델은 개발자가 애플리케이션을 개발하는데 밑거름이 된다.

 

매장 주문

• OrderTable은 식별자와 이름, NumberOfGuests를 가진다.
• OrderTable의 추가 Order는 OrderTable에 계속 쌓이며 모든 Order가 완료되면 EmptyTable이 된다.
• EmptyTable인 경우 NumberOfGuests는 0이며 변경할 수 없다.
• Order는 식별자와 OrderStatus, 주문 시간, OrderLineItems를 가진다.
• 메뉴가 노출되고 있으며 판매되는 메뉴 가격과 일치하면 Order가 생성된다.
• Order는 접수 대기 ➜ 접수 ➜ 서빙 ➜ 계산 완료 순서로 진행된다.
• OrderLineItem는 가격과 수량을 가진다.
• OrderLineItem의 수량은 기존 Order를 취소하거나 변경해도 수정되지 않기 때문에 0보다 적을 수 있다.

 

모델링은 사업팀도 이해할 수 있도록 작성해야 한다.

개발 용어가 포함되지 않도록 작성한다.

클래스 다이어그램이 아닌 mermaid를 활용해 이해하기 쉽게 도식화 한다.

 

---

 

2. 전략적 설계 - BOUNDED CONTEXT

같은 모델에 대해 컨텍스트별로 바라보는 관점이 다르기 때문에 용어 사전 정의와 도메인 모델링은 컨텍스트 별로 이루어 져야 한다.

• Sales Context 관점의 Customer: 상품을 구매하는 고객
• Support Context 관점의 Customer: 상담을 요청하는 고객

Sales Context 에서는 고객의 생일 정보를 통해 생일 할인 이벤트를 적용해볼 수 있지만

Support Context 에서 고객의 생일 정보는 불필요할 수 있다.

 

하위 도메인마다 사용하는 용어가 다르기 때문에 올바른 도메인 모델을 개발하려면 하위 도메인마다 모델을 만들어야 한다.
모델은 특정한 컨텍스트(문맥)하에서 완전한 의미를 갖는다.
이렇게 구분되는 경계를 갖는 컨텍스트를 DDD에서는 BOUNDED CONTEXT라고 부른다.

 

 

좋은 BOUNDED CONTEXT

• 하나의 BOUNDED CONTEXT는 하나의 팀에만 할당되어야 한다.
• 하나의 팀은 여러 개의 BOUNDED CONTEXT를 다룰 수 있다.
• 각각의 BOUNDED CONTEXT는 각각의 개발 환경을 가질 수 있다.

 

CONTEXT MAP

컨텍스트 맵은 상호 교류하는 시스템의 목록을 제공하고, 팀 내 의사소통의 촉매 역할을 한다.

프로젝트와 조직 관계

• 파트너십(Partnership) : 두 CONTEXT가 하나의 트랜잭션으로 묶여 있다.
• 공유 커널(Shared kernel) : 상호 의존하는 공유 모델을 관리한다.
• 고객-공급자(Customer-Supplier Development) : 업스트림(서버:공급자), 다운스트림(클라이언트:고객)로 단방향으로 의존
• 한다.
• 순응주의자(Conformist) : 업스트림(서버)이 모든 것을 제어한다.
• 오픈 호스트 서비스(Open Host Service) : REST/API, RPC, Socket
• 분리된 방법(Seprate Ways) : 의존 없음
• 큰 진흙공(Big ball of mud) : 안티 패턴

 

DDD vs OOP

DDD는 OOP에 근간을 두고 있지만 ID를 사용한 간접참조, 값 객체의 사용 등은 OOP를 위반하는 내용일 수 있다.

OOP는 상속과 재사용성을 중요시하지만 DDD는 도메인의 분리를 중요시한다.

 

---

3. 이벤트 스토밍(Event Storming)

DDD 도입을 위해 이벤트 스토밍을 진행한다.

• 복잡한 비즈니스 도메인을 빠르게 탐색하고 학습할 수 있는 워크숍
• 도메인 전문가와 개발자를 학습 과정에 참여시키기 위한 빠른 설계
• 코드를 없애고 모든 사람을 동일한 수준으로 만드는 시각적 접근 방법

 

1단계: 혼란스러운 탐험

각자가 알고 있는 도메인 이벤트를 작서하도록 요청한다.

각자가 작성한 이벤트는 볼 수 있지만, 토론을 시작하지 말고 자신이 옳다고 생각하는 방식으로 기록한다.

도메인 이벤트 - 주황색

• 이벤트 전문가가 관심이 있는 어떤 사건
• 이벤트 이름은 과거에 일어났던 일을 표현하기 때문에 과거 시제를 사용한다.
• 이벤트가 발생한다는 것은 상태가 변경되었다는 것을 의미한다.

 

2단계: 타임라인 적용

모든 도메인 이벤트를 올바른 타임라인으로 정렬하고 실제로 중복되는 이벤트를 제거한다.

시간은 왼쪽에서 오른쪽으로 흐르고, 위에서 아래로 평행한 시간을 표현할 수 있다.

핫 스폿 - 자주색

• 2단계에서 발생한 갈등을 시각화하고 캡쳐하는 데 사용한다.
• 당장 토론하지 않는다. 나중에 문제가 해결되면 제거한다.

액터와 시스템 - 노란색과 분홍색

단순한 '사용자' 또는 '고객'보다 구체적인 페르소나를 설정한다.

외부 시스템으로부터 일부 레거시 및 마이크로 서비스에 이르기까지 책임을 전가할 수 있는 모든 것

 

바운디드 컨텍스트

같은 용어라도 의미가 다르고 같은 대상이라도 지칭하는 용어가 다를 수 있다.

명백한 언어 불일치는 종종 동일한 프로세스 내에서 여러 개의 바운디드 컨텍스트를 나타내는 지표이다.

 

커멘드 또는 액션 - 파란색

• 시스템에서 일어나는 일
• 도메인 이벤트가 발생하는 원인

리드 모델 또는 정보 - 초록색

• 결정을 내리는데 필요한 정보

정책 - 연보라색

• 주로 `~할 때마다'라는 단어로 시작한다.
• 도메인 이벤트와 커멘드 사이에 위치한다.

 

에그리게잇 또는 비즈니스 규칙 - 연노란색

• 시스템이 기대하는 책임을 수행하는 일관성을 유지하는 단위
• 일관성은 항상 참이어야 하는 속성을 유지함으로써 달성된다.

 

자산화

Miro

 

이벤트 스토밍으로 얻을 수 있는 것

• 모두가 서로에게서 배운다.
• 모두가 서로 소통한다.
• 자신의 관점에서 문제를 발견하면 누구나 말할 수 있다.
• 모두가 문제를 해결하는 방법에 대한 자신의 아이디어를 제공한다.
• 워크숍 후에는 모두가 같은 사실을 알게된다.

 

 

 

 

 

출처

NEXTSTEP: DDD 세레나데 3기