DDD 원칙(Domain Driven Design)이란?

 

 

 

 

 

 

 

 

DDD 의 철학

1. DDD(Domain Driven Design, 도메인 주도 설계)란 는 비즈니스 도메인에 깊이 집중하여 이를 기반으로 소프트웨어를 설계하는 방법론이다.
2. 비즈니스 요구사항을 도메인 모델로 표현하고, 이를 통해 도메인의 책임과 역할을 명확히 반영하는 것을 목표로 한다.
3. DDD는 비즈니스 도메인을 잘 이해하고 이를 소프트웨어에 녹여내는 데 중점을 두며, 설계 단계에서부터 코드가 도메인의 본질을 명확히 반영하도록 함으로써, 비즈니스와 기술 간의 간격을 줄이고 코드 자체가 도메인의 문서 역할을 하도록 만드는 것이 그 핵심 철학이다.
   1. 예를 들어, 산지 직송 이라는 상위 도메인을 기반으로 애플리케이션을 개발할 때, 각 세부적인 기능을 ‘회원', ‘상품’, '주문', '결제', '혜택’, '배송'과 같은 하위 도메인으로 나누어 역할을 정의할 수 있다.
   2. 이러한 과정을 통해 각 도메인이 무엇을 책임지고, 어떤 역할을 수행해야 하는지를 명확히 할 수 있다.
4. 이렇게 도메인 모델을 설계하고 나면, 각 도메인이 맡는 역할과 책임이 코드에 자연스럽게 반영되며,
   이를 통해 "코드가 곧 문서화"라는 철학과 연결되는데, DDD에서는 코드가 비즈니스 로직과 도메인을 직접 표현하기 때문에, 별도의 문서 없이도 코드만으로 시스템의 설계와 동작을 이해할 수 있게 되는 것.
5. DDD는 단순한 폴더 구조가 아니라 복잡한 비즈니스 로직을 도메인 중심으로 설계하는 방법론.
6. DIP는 이 설계를 기술적으로 구현할 때 도메인의 독립성을 보장하는 원칙으로 작동한다.

 

DDD의 핵심 구성요소

전략적 설계 (Strategic Design)

• Business Domain의 상황(Context: 대상사용자, 상황)에 맞게 설계하자는 컨셉
• 전략적 설계를 위해 Business Domain을  목적별로 서비스들을 그룹핑합니다.

개념	기준	실무 예시
Bounded Context	복잡한 시스템을 어떤 경계로 나눌 것인가?	- 같은 용어가 다른 의미를 갖는 경계   (e.g. 상품) - 주문: 주문 품목, - 가격 배송: 무게, 크기
Ubiquitous Language	개발자와 기획자가 동일한 용어 사용 → 코드에 그대로 반영	- 기획: "주문 확정" 코드: order.confirm()  - 기획: "배송 시작" 코드: delivery.start()
Context Map Bounded	Context 간의 관계 정의	- 결제 Context의 변경이 주문 Context에 영향을 줌  - [주문 Context] 고객/공급자  - [결제 Context]

 

전술적 설계(Tactical Design)

• 하나의 Bounded Context 안에서 코드를 어떻게 구성할 것인가
• Strategic = "어디서 자를까" (경계 설정) Tactical = "안에서 뭘 만들까" (빌딩 블록)

Strategic Design                    Tactical Design
───────────────                    ────────────────
시스템을 Context로 분리         →       각 Context 내부를 
                                    Aggregate(함께 취급되어야 하는 객체들의 집합)로 구성

    [전체 시스템]                      [하나의 Context]
   ┌───┬───┬───┐                  ┌─────────────────┐
   │ A │ B │ C │  Context         │ Aggregate들로    │
   └───┴───┴───┘                  │ 구성             │
                                  └─────────────────┘