DDD(도메인 주도 설계)에 대해 들어봤지만, '어디서부터 시작해야 할지 모르겠다'고 생각하는 분들이 많을 것입니다.
이 입문 가이드에서는 복잡한 비즈니스 로직을 코드로 정확하게 표현하기 위한 기본 개념과 실천 방법을 설명합니다.
핵심 원칙은 개발자와 비즈니스 측에서 동일한 용어를 사용하는 것입니다.
'예약'과 '일정(스케줄)'은 업무상으로는 서로 다른 개념일 수 있습니다. 명확한 구분이 없다면 코드 상에서도 혼란이 발생합니다. DDD에서는 코드 내부의 이름도 업무용어에 맞춥니다.
ID로 식별되는 객체 (Identity)
# 예: 예약은 ID로 식별됩니다
reservation1 = Reservation(id="R001", guest_name="田中", ...)
reservation2 = Reservation(id="R002", guest_name="田中", ...)
...
속성만으로 식별되는 객체 (Attribute). 불변(immutable)합니다.
from dataclasses import dataclass
@dataclass(frozen=True)
class GuestCount:
...
GuestCount(4)와 GuestCount(4)는 속성이 같기 때문에 같은 것으로 취급됩니다.
일관성을 유지하는 단위 (Consistency Unit). 외부에서는 집약 루트(Aggregate Root)를 통해서만 접근합니다.
예약(집약 루트) ← 예약 아이템 ← 예약 옵션
단일 엔티티에 속하지 않는 비즈니스 규칙.
예: '중복 예약 체크' — 하나의 예약 엔티티만으로는 판단할 수 없습니다.
from dataclasses import dataclass
from enum import Enum
...
| DDD에 적합한 경우 | DDD가 필요 없는 경우 |
|---|
| ✅ 예약 시스템, 재고 관리, 계약 관리 등 업무 규칙이 복잡함 | ❌ 단순한 CRUD 애플리케이션 |
| ... | |
| DDD는 클린 아키텍처(Clean Architecture)의 Domain 계층을 풍부하게 만드는 방법입니다. | |
Domain 계층 (DDD로 설계) → UseCase 계층 → Adapter 계층 → Framework 계층
DDD로 설계한 도메인 모델을 클린 아키텍처의 레이어 구조에 배치합니다.
DDD의 핵심은 **'비즈니스 규칙을 코드로 정확하게 표현하는 것'**입니다.
| 개념 | 역할 |
|---|
| 유비쿼터스 언어 (Ubiquitous Language) | 업무용어 통일 |
| ... | |
| 복잡한 업무 로직을 가진 시스템이라면, DDD의 사고방식을 도입해 보세요. | |
본 기사는 개인 Zenn에서도 공개되었습니다.
