DDD: Domain Driven Design

오늘 공부한 것은 많은데,, 정리하는데 시간이 좀 걸리는 것 같다. 일단 DDD부터.

- DDD << 여기 !

- REST API

- Swagger

---

Domain Driven Design

도메인 주도 설계

도메인 패턴을 중심에 놓고 설계하는 방식

실제 우리가 해결하려는 분야(Domain)의 핵심 문제와 비지니스 요구사항을 이해하고 이를 소프트웨어 모델에 명확히 반영하는 것을 최우선으로 한 소프트웨어 개발 방법론

 

왜? 써야하지?

도메인 모델의 적용 범위를 구현까지 확장하여, 도메인 지식을 구현코드에 반영한다.

공통의 언어(유비쿼터스언어)를 사용하여 도메인과 구현을 충분히 만족하는 모델을 만든다.

실제 코드로 구현 가능한 현실성이 있는 도메인 모델 분석과 그것을 추상화 하는 설계다.

 

분류

전술적 설계 (Tactical Design)

각 영역(Context, Bounded Context) 도메인 모델을 만들고 구현하는 방법에 중점.

⇒ 어플리케이션을 개발하기 위한 구체적인 설계과정

 

전략적 설계 (Strategic Design)

개념에 대해 정의하고 설계를 하는것에 중점.

도메인을 서로 다른 영역으로 나눈다.

각 영역(Context)에서 일관된 용어와 모델을 사용하여 각 영역과 관련해 팀원과 소통

각 영역을 독립적으로 발전 → 유지보수 쉬워짐

⇒ 소프트웨어를 설계하기 전 요구사항에 대하여 명확하게 정의하고, 개념적인 설계를 하는 과정

 

용어 정의

Ubiquitous Language

   공통된 언어(단어)를 통해 개발자와 도메인 전문가를 포함한 팀원들 간 일괄된 언어를 사용하자는 개념

   모델링에 사용되고, 코드와 문서에도 반영 됨.

   → 코드의 가독성을 높여 코드를 분석하고 이해하는 시간을 절약한다.

 

Domain

   일반적인 요구사항, 소프트웨어로 해결하고자 하는 문제 영역

 

Domain Event

   도메인에서 발생하는 사건(이벤트)들.

   주로 과거 시제로 기록

   (e.g. 로그인에 성공함, 상품이 배송됨)

 

Actor

   도메인에 속해있는 사용자

 

Command

   Domain Event를 유발시키는 명령.

   주로 API와 대응됨

 

Policy

   도메인 내의 규칙

   Domain Event 뒤에 따라오는 하나의 비지니스 로직

   Policy에 의해 다른 Event가 Trigger될 수 있음

   (e.g. 매월 카드 결제일이 되면 계좌에서 결제 대금이 빠져나간다.)

 

External System

   이메일 전송 시스템, 결제 시스템 등 외부 시스템

   외부시스템에 의해 Event가 트리거 되기도 함

 

Hotspot

   의문, 질문, 미결정 사항

 

Aggregate

   비지니스 로직을 수행하기 위한 데이터 객체의 집합

   (e.g. 주문 aggregate : 배송정보, 결제 정보와 같은 Domain Model로 이루어져 있음)

   모델간의 경계를 잘 정의할 수 있음.

   코드의 일관성을 유지할 수 있음.

   도메인이 복잡할 경우 유용함.

 

Bounded Context

   Actor, Domain Event, Command를 고려한 하나의 집합

   (e.g. 쇼핑몰

         회원 Context : 회원가입, 정보수정

         상품 Context : 상품 주문 및 결제

         배송 Context : 배송 담당 )

   Bounded Context는 복잡한 비지니스 도메인에서 이를 구분하고, 관리하기 위해 사용됨

   각 컨텍스트 별로 담당하는 조직이 나뉘기도 함

   Architecture로 분리되기도 함.

 

디자인 과정 - Event Storming

1. 각 요소별로 상징색 혹은 모양을 설정한다. 여기서 요소는 위의 용어에 정의된 Actor, Domain, Event, Command, Policy, External System, Hotspot, Aggregate다.
2. Actor를 정의한다.
3. Domain Event를 모두 나열한다.
   • 시간의 순서에 맞게 나열하는 것이 좋다.
   • 이벤트를 정의하는 도중 필요시, Policy와 Hospot을 정의한다.
4. Event 앞에 Command를 붙인다.
5. Event 뒤에 External System이 필요할 시 덧붙인다.
6. Command 앞에 Actor를 설정한다.
7. Event들을 그룹핑하여 Domain Model 및 Aggregate를 정의한다.
8. 필요시, Bounded Context를 정의한다.
9. Model의 Data(Model이 담고 있는 정보)에 대해 정의한다.

 

 

---

지금... DDD를 하나 작성해보고 있다. 개념만 아는 것 보단 역시, 실제로 구현해보는것이 짱...!