도메인 주도 설계 (DDD, Domain-Driven Design) 란?

DDD (Domain-Driven Design) 는 복잡한 비즈니스 로직을 다루는 애플리케이션에서
도메인(업무 영역)을 중심으로 설계를 이끌어나가자는 접근 방식이다.

도메인을 중심에 두고, 코드 구조와 용어, 모델까지 비즈니스와 일치시키는 것이 핵심이다.

도메인(Domain)이란?

시스템이 해결하려는 문제 영역, 혹은 비즈니스의 개념적 범위

예를 들어, 뱅킹 애플리케이션을 개발한다고 할 때의 도메인은 다음과 같다:

• 계좌 (Account)
• 고객 (Customer)
• 잔액 (Balance)
• 이자율 (InterestRate)
• 입출금 (Transaction)

즉, 도메인은 해당 시스템이 작동하는 현실 세계의 개념이고,
애플리케이션이 반영해야 할 실제 비즈니스 규칙과 개념들이다.

도메인 모델(Domain Model)이란?

도메인을 코드로 옮긴 것이 바로 도메인 모델이다.

"현실 세계의 개념과 규칙을 소프트웨어 구조로 표현한 것"

여기서 중요한 건 단순히 데이터를 담는 것이 아니라, 행위(behavior)와 비즈니스 규칙까지 캡슐화한다는 점이다.
DTO나 단순 Entity와는 다르게, 비즈니스 의미를 그대로 담고 있는 객체 집합이다.

예시: 도메인 모델로서의 Account

public class Account {
    private Long accountId;
    private BigDecimal balance;
	
    public void deposit(BigDecimal amount) {
        if (amount.compareTo(BigDecimal.ZERO) <= 0) {
            throw new IllegalArgumentException("입금 금액은 0보다 커야 합니다.");
        }
        this.balance = this.balance.add(amount);
    }
	
    public void withdraw(BigDecimal amount) {
        if (balance.compareTo(amount) < 0) {
            throw new IllegalStateException("잔액 부족");
        }
        this.balance = this.balance.subtract(amount);
    }
}

여기서 Account 객체는 단순한 데이터 구조가 아니라,
"입금", "출금"이라는 행위를 직접 가지고 있는 비즈니스 개체다.
이게 바로 DDD에서 말하는 도메인 모델의 핵심이다.

DDD를 왜 쓰는가?

• 복잡한 도메인을 모델링 중심으로 이해하고 해석하기 위함
• 비즈니스와 코드가 동일한 언어로 맞닿아 있어야 변화에 강함
• 단순 계층적 CRUD 설계로는 감당하기 어려운 규칙 중심 시스템에 적합

핵심 요약

용어	의미
도메인	시스템이 해결하고자 하는 비즈니스 문제 영역
도메인 모델	도메인을 코드로 표현한 것. 상태 + 행위 + 규칙 포함
Entity	고유 식별자를 갖는 도메인 객체
Value Object	식별자가 없고 값 자체로 의미를 가지는 객체 (ex. Money, Address 등)

마무리

DDD는 "개발자가 코드로 비즈니스를 이해한다"는 철학이다.
단순한 설계 방식은 아니지만, 복잡한 시스템일수록 DDD의 힘이 발휘된다.

"소프트웨어는 결국 비즈니스를 반영하는 도구다.
그렇다면 비즈니스 중심의 설계가 되어야 하지 않을까?"