[TIL] DDD 개념 & 설계 사고방식

DDD란?

DDD는 복잡한 비즈니스 도메인을 효과적으로 모델링하기 위한 설계 방법론이다.

 

DDD(Domain-Driven Design)은 Eric Evans가 2003년에 정리한 소프트웨어 설계 방법론이다. 이는 "도메인 모델링"이 소프트웨어 설계 중심이라는 것에서 출발한다. 개발자와 도메인 전문가가 공통된 언어를 사용하여 문제 영역을 정의하고, 모델을 기반으로 설계와 구현을 긴밀히 연결하는 방법을 탐구한다. 코드와 비즈니스 개념 사이의 간극을 줄여 시스템의 장기적인 유연성을 높이는 것을 핵심적인 목표로 한다.

 

DDD의 등장 배경

기존 개발 방식의 한계

과거 엔터프라이즈 시스템은 아래와 같은 DB를 중심으로 하는 구조가 일반적이었다.

Controller → Service → DAO → DB

 

그러나 이러한 구조는 아래의 문제점으로 인해 유지보수도 힘들어질 뿐더러 복잡한 도메인을 모델링하기가 상당히 힘들었다.

• 서비스에 로직이 다 몰림
• 비즈니스 규칙이 여기저기 흩어짐
• 요구사항이 바뀌면 영향 범위가 커짐 (비즈니스가 복잡해질수록 코드가 감당안될 정도로 복잡해지)

이러한 설계의 문제점을 해결하고자 등장한 것이 DDD이다.

 

 

DDD의 목적

복잡한 도메인 관리

order.cancel();
order.refund();
order.ship();

 

이러한 메서드 내에는 단순히 메서드명만을 포함한 기능뿐만 아니라 아래와 같은 도메인 비즈니스 로직이 필수적으로 포함되기 마련이다.

• 취소 가능 상태인지 확인
• 이미 배송됐는지 체크
• 환불 정책 적용
• 위약금 계산

DDD는 이 로직을 도메인 객체가 스스로 책임지게끔 한다.

• 비즈니스 개념을 코드에 그대로 녹이게끔 한다.
• 도메인 전문가와 개발자가 같은 언어를 쓰게 한다.
• 모델이 시스템의 중심이 되게 만드는 것

 

비즈니스 규칙 중심 설계

기존 방식에서는  Service 레이어에서 아래와 같은 식으로 예외 처리를 하게 된다. 즉, Service에서 상태를 판단하게 된다.

if (order.status == CANCELLED) throw ...

 

DDD 방식에는 위 상태 판단 코드를 엔티티 내부에서 스스로 판단하게끔 한다.

order.cancel();

기존 방식	DDD
로직이 Service에 있음	로직이 도메인 객체에 있음
DB 중심	도메인 중심
절차적	객체지향적

 

---

 

 

DDD의 핵심 사고방식

도메인을 이해하는 것이 먼저다

DDD에서는 기술이 아니라 비즈니스가 중심이다. 따라서 기존 방식대로 요구사항을 정의하고 DB 테이블을 설계하는 것 이전에 서비스의 핵심 비즈니스 로직이 무엇인지에 대해 중점적으로 이해하는 것이 권장된다.

• 이 서비스의 핵심 개념은?
• 이 비즈니스의 규칙은?
• 상태는 어떻게 변하는가?
• 불변 조건은 무엇인가?

 

도메인 모델이 중심이다

기존의 CRUD 방식에서는 아래와 같은 구조가 일반적으로 쓰인다.

Controller → Service → Repository

 

그러나 DDD에서는 도메인 모델을 중심으로 아래와 같이 이러한 구조를 쓴다. 즉, 비즈니스 규칙은 Entity안에 들어가게 된다.

domain/
 ├── entity
 ├── value object
 ├── repository (interface)
 ├── domain service
application/
infrastructure/
presentation/

 

기존 CRUD 방식

// 서비스 레이어에서
order.setStatus("COMPLETED");

 

DDD 방식

DDD 방식에서는 기존의 비즈니스 규칙을 서비스 레이어가 아닌 Order 객체의 내부에 두게 한다.

// 서비스 레이어에서...
order.complete();

// Order 객체의 complete 함수 내부에서
if (!isPaid()) {
    throw new IllegalStateException();
}

 

 

---

 

도메인 모델 vs 트랜잭션 스크립트 패턴

트랜잭션 스크립트 패턴

Patterns of Enterprise Application Architecture라는 책에서 저자 마틴 파울러 가 정리한 개념이다.

 

• 하나의 요청 = 하나의 서비스 메서드
• 비즈니스 로직이 Service에 몰려 있음
• Entity는 단순한 데이터 구조 (Anemic Model)
• 도메인 규칙이 분산됨
• 규모 커지면 유지보수 어려움
• CRUD에 적합
• 빠르게 개발 가능

 

아래와 같이 일반적으로 Service 레이어에 있는 함수 내에 비즈니스 로직이 몰려있는 구조라고 보면 된다.

public void completeOrder(Long orderId) {
    Order order = orderRepository.findById(orderId);
    
    if (order.getStatus() != PAID) {
        throw new IllegalStateException();
    }

    order.setStatus(COMPLETED);
    orderRepository.save(order);
}

 

 

 

도메인 모델 패턴 (Domain Model)

DDD가 지향하는 방식으로 비즈니스 로직이 객체 내부에 위치해있고, Entity가 행위를 가지는 형태이다. 그리고 객체가 자신의 상태를 스스로 핸들링한다.

• 응집도 높음
• 비즈니스 규칙이 객체에 모임
• 복잡한 도메인에 강함

// service layer
order.complete();


// order 객체
public void complete() {
    if (!isPaid()) {
        throw new IllegalStateException();
    }
    this.status = COMPLETED;
}

 

 

---

 

Layered Architecture에서 DDD의 위치

 

Layered Architecture라는 아키텍처 패턴이 있다. 이에 대한 자세한 내용은 이전 포스팅에 정리해두었으니 아래를 간단히 참고하면 된다.

https://miiiiiin-devlog.tistory.com/110

[DELIVERY_SIGNAL] DDD 계층 구조 적용

 

•  Presentation Layer : 사용자(클라이언트)의 요청을 받고 응답을 반환 (Controller, DTO 반환)
  • DDD 관점: 비즈니스 로직을 몰라야 하며, 단순히 사용자의 의도를 Application Layer로 전달
• Application Layer : 비즈니스 로직을 직접 수행하지 않고, 도메인 객체들이 협력할 수 있도록 흐름 제어
  • DDD 관점: 트랜잭션 관리, Use Case 실행, 리포지토리 조회/저장 등을 담당하는 오케스트레이터
• Domain Layer : DDD가 여기에 위치함. 비즈니스 규칙과 로직을 담고 있음. (Entity, VO, Aggregate, Domain Service)
  • DDD 관점: 외부 계층에 의존하지 않고 고립되어야 하며, 실제 비즈니스 결정이 이곳에서 이루어짐
• Infrastructure Layer : 기술적인 세부 사항을 구현 (JPA 구현체, 메시지 큐, 외부 API 통신)
  • DDD 관점: 도메인 계층에서 정의한 Repository 인터페이스의 실제 구현체가 이곳에 위치 (의존성 역전 원칙 적용 시)

 

Presentation : Controller, Request/Response 변환 (여기에는 비즈니스 로직이 없어야 한다.)
Application : Use Case 실행, 여러 Aggregate 조합, 트랜잭션 관리 (비즈니스 규칙을 가지지 않는다.)
Domain : DDD 위치 (모든 비즈니스 규칙은 여기 존재해야 함)
Infrastructure : JPA 구현체, 외부 API (Repository 인터페이스는 Domain에 두고, 구현은 Infrastructure에 둠)

 

DDD는 이 중에서 Layered Architecture에서 Domain Layer의 설계 방식에 속한다.

DDD는 아키텍처가 아니고,  Domain Layer를 어떻게 설계할 것인가에 대한 방법론이다. 

 

 

---

 

DDD를 언제 쓰고, 언제 안쓰는가?

DDD를 써야 하는 경우

• 비즈니스 규칙이 복잡할 때
• 상태 전이가 많을 때
• 정책이 많고 자주 바뀔 때
• 도메인 전문가와 협업이 중요할 때
• 금융 시스템, 정산 시스템, 커머스 주문/결제, 멤버십/포인트 시스템 등..

 

DDD가 과한 경우

• 단순 CRUD
• 비즈니스 규칙 거의 없을 때
• MVP 단계

---

 

DDD와 MSA의 관계

DDD는 도메인 레이어 설계 철학이고, MSA는 배포 및 서비스 분리 아키텍처이다.

DDD와 MSA가 같은 개념은 아니지만, DDD의 핵심 개념 중 하나인 Bounded Context 개념이 MSA 분리에 영향을 주는 경우가 많디.

 

 

 

참고

https://yeseul-dev.tistory.com/69

DDD에 대해서 간단하게 정리하기