도메인 주도 설계 (Domain Driven Design )

 

도메인 주도 설계 란?

 " 도메인과 일치하도록 소프트웨어를 모델링하는 데 중점을 둔 소프트웨어 설계 접근 방식.

중요한 특징은 소프트웨어 코드의 구조와 언어(클래스 이름, 클래스 메소드, 클래스 변수 )가 비즈니스 도메인의 용어를 일치시켜 나간다는 점 " <WIKI>

 

도메인 주도가 필요한 이유

모놀리식으로 개발시 마구잡이식으로 영역 구분없이 어플리케이션을 개발하면, 추가 개발 등의 업무를 진행할때, 영역 구분이 없는 어플리케이션을 수정해야 하므로, 영향범위를 파악하기 어렵고, 최악의 경우는 하나의 수정을 위해 이미 개발해놓은 모든것을 수정해야 할 수도 있다.

 

도메인 

도메인

실 세계에서 사건이 발생하는 집합이다. 실제 소프트웨어로 구현되어야 할 행동 영역이다.

 

 

이커머스 도메인

 

도메인 주도 설계에서 도메인을 먼저 정의 한다.

실제 구현될 모델보다는 단순화된 모델로써, 이 모델을 이용해 유비쿼터스 언어등을 정의하고 모델을 설계하기 위해서 꼭 필요한 구성 요소이다. 

 

 

 

서브 도메인 (sub-domain)

비지니스도메인을 구성하는 하위 도메인이다. 즉 서브 도메인이 합쳐져 비지니스 도메인을 이루는 것이다.

서브 도메인은 3가지로 나뉘는데

• 핵심 도메인 (core sub-domain) : 다른 경쟁자와 차별화를 만들 수 있는 비지니스 영역
• 지원 도메인 (supporting sub-domain) : 비지니스에 필수적이지만 핵심적이지 않은 영역
• 일반 도메인 (generic sub-domain) : 특화되거나 필수적이지 않은 비니지스 솔류션을 지원할 수 있는 영역

 

 

도메인 모델?

 도메인을 동일한 관점에서 이해할수 있고 모두가 공유할수 있도록 단순화 / 시각화 하여 개념적으로 표현한것이다.

 

 

 

 도메인 모델에는 4개의 영역이 존재 한다.

 

 

 

도메인 주도 설계

도메인 주도 설계는 크게 전략적설계, 전술적 설계 두가지로 나눌 수 있다.

 

전략적 설계 (Strategic Design)

전략적 설계는 비지니스상 전략적으로 중요한 것을 구분하고 찾는 과정으로 도메인 전문가 및 기술팀이 함께 모여 유비쿼터스 언어를 통해 도메인 지식을 공유 및 이해하고 이를 기준으로 개념과 경계를 식별해 바운디드 컨텍스트(bounded context)로 정의하고 경계의 관계를 컨텍스트 맵(context map)으로  정의하는 활동이다. 

 전략적 설계가 끝나면 도메인 모델을 얻을 수 있다.

 

유비쿼터스 언어

 특정 도메인에서 특정용어가 해당 도메인의 의도를 명확하게 반영하고, 핵심 개념을 잘 전달 할수 있는 언어이다.  유비쿼터스 언어는 개발자. 도메인 전문가, 등 모든 사람이 동일한 의미로 사용되어야 하다. 모든 팀원들이 특정용어를 들었을때, 같은 것을 생각할 수 있게 명확하게 정의 되어야 하며, 혼돈의 여지가 있으면 안된다. 이 용어는 개발 코드에 그대로 반영되어 코드의 역할을 명확하게 해야 한다.

 이러한 용어는 사전을 관리하여 명확한 의미가 지속적으로 이어질 수 있도록 관리 되어야 한다.

 

컨텍스트 (Context) 란?

 그때그때 상황에 맞게끔 실행/판단/결정 등을 해야 하는 집합을 컨텍스트로 정의한다. 어떠한 상황이 별어지고있는 상황의 경계/집합 이다.

 

바운디드 컨텍스트 (Bounded Context)

도메인 모델의 범위/경계이다. 도메인들의 집합이라고 할수 있다. 바운디드 컨텍스트와 서브도메인간에는 범위에 따라 1:1, 1:N, N:1 로 매핑 될수 있다. 서브 도메인이 어려거의 바운디드 컨텍스트에 포함 될 수 있다는것이다.

 바운디드 컨텍스트는 실제로 모델이 구현되고, 곧 개별 개발 산출물이 나오게된다. 바운디드 컨텍스트는 유비쿼터스 언어를 이용해 명확하게 정의 해야 한다. 

 바운디드 컨텍스트를 나누는 과정은 이벤트 스토밍 방법론을 활용한다.

 

이벤트 스토밍 (Event Storming) - 바운디드 컨텍스트를 나누기 위한 방법론

 이벤트 스토밍이란 비지니스 토메인 내에서 일어나는 행동을을 찾아 Bounded Context 를 식별 하는 방법론이다.

 

• Step 1. Domain Event 정의
  비지니스 도메인내에 발생하는 모든 이벤트를 작성한다. 이벤트는 행위자(Actor)가 행동(Action)을 해서 발생한 결과(Event) 로 "~이 되었다"의 과거 시제로 작성 한다. 
  이때, 모든 Event 를 빠짐없이 나열하는게 중요하다.
  예 > 상품을 주문하였다. 상품을 배송하였다. 상품이 등록되었다. 등.
  
  
• Step 2. 이벤트의 흐름대로 나열 
  이전 단계에서 작성한 이벤트를 시간적 흐름에 따라 순서대로 나열하고, 동시에 발생한 이벤트는 병렬로 나열한다.
  돌출된 이벤트를 참가자와 함께 토론하여 보완한다.
  
  Step 3. 프로세스로 그룹핑
  동일한 업무유형의 이벤트들을 하나의 프로세스로 그룹핑한다.
  
  
• Step 4. Command 정의
  각 Domain Event를 발생시키는 명령정의한다. 이때 명령은 현재형으로 "~을 ~한다" 의 형태로 기술한다.
  일반적으로 Command 는 Event 의 시제가 과거에서 현재로 변경된 형태를 띈다.
  예 > 상품을 주문 한다. 상품을 배송한다. 상품을 등록한다. 등
  
  
• Step 5. Trigger/Actor 정의
  Command를 일으키는 Actor와 Event를 일으키는 외부 시스템 등을 정의한다.
  예 > 상품을 주문한다 => "고객이" 상품을 주문한다.
  
  
  
• Step 6. Aggregate 정의
  Command 수행을 위해 CRUD해야 하는 데이터 객체 정의 
  Entity : 
  VO : 
  
  
• Step 7.Bounded Context 정의
  
  
• Step 8. Context Map 작성

 

컨텍스트 매핑 (Context Mapping) 

 바운디드 컨텍스트 간의 매핑 관계를 말한다. 바운디드 컨텍스트는 상호작용을 하기 위해 연동을 필요로 하는데, 이 둘사이에 선을 그어 매핑관계를 나타낸다.  두 바운디드 컨텍스트간에 통신을 의미 하므로, 명확하게 설정해야 하며, 한번 설정한 관계에해서는 각 영역간 협의 없이 변경 되지 않아야 한다.

 컨텍스트 매핑은 SOAP, RestFul API, TOPIC 등으로 구현될 수 있다.

 

 

 

 

전술적 설계 (Tactical Design)

전략적 설계에서 도출된 바운디드 컨텍스트와 도메인을 이용하여 애그리거트 패턴, 엔티티와 값 객체, 레포지토리, 등을 구성하고 구현하는 활동

 

Aggregate (집합)

 

 

 

참고1 : https://brunch.co.kr/@springboot/605

 

[스터디]도메인 주도 설계 1주차

 

참고 2 : https://happycloud-lee.tistory.com/94

DDD 핵심만 빠르게 이해하기