4. DDD (도메인 주도 개발)

May 01, 2026

Contents

1. DDD (Domain Driven Design, 도메인 주도 개발)1️⃣ DDD란?2️⃣ 왜 DDD를 사용하는가?3️⃣ 핵심 개념 (필수)4️⃣ DDD 구조 (Spring 기준)5️⃣ 실무 예시 (중요)6️⃣ DDD의 장점 / 단점 7️⃣ 한 줄 핵심 정리

1. DDD (Domain Driven Design, 도메인 주도 개발)

1️⃣ DDD란?

1) 정의

도메인(업무 영역)을 중심으로 설계를 하는 개발 방법론

기술이 아니라 비즈니스 로직 중심으로 설계하는 것이 핵심

“코드를 기술 기준이 아니라, 업무(비즈니스) 기준으로 나누자”

2) 도메인이란?

소프트웨어가 해결하려는 업무 영역

예시

쇼핑몰 → 주문, 결제, 배송
은행 → 계좌, 송금, 이자

2️⃣ 왜 DDD를 사용하는가?

1) 기존 문제점 (CRUD 중심 개발)

Controller → Service → Repository 구조만 있음

비즈니스 로직이 Service에 몰림

문제

코드가 점점 복잡해짐
유지보수 어려움
협업 시 의미 전달 어려움

2) DDD의 해결 방향

업무 개념을 코드에 그대로 반영

개발자 ↔ 기획자 간 언어 통일

핵심 키워드

도메인 중심
의미 있는 코드 구조
복잡도 관리

3️⃣ 핵심 개념 (필수)

1) 엔티티 (Entity)

특징

고유 식별자(ID)가 있음

상태가 변해도 같은 객체


class Order {
    Long id;
    String status;
}

👉 주문 상태는 바뀌지만 같은 주문

2) 값 객체 (Value Object)

특징

값 자체가 의미

불변(immutable)

equals로 비교


class Address {
    String city;
    String street;
}

👉 주소는 ID보다 값이 중요

3) 애그리거트 (Aggregate)

개념

관련 객체를 하나의 묶음으로 관리

중심이 되는 객체 → Aggregate Root


Order (Root)
 ├─ OrderItem
 └─ Address

👉 외부에서는 Order만 접근 가능

필요한 이유

데이터 무결성 유지

트랜잭션 경계 설정

4) 리포지토리 (Repository)

역할

DB 접근 추상화


interface OrderRepository {
    Order findById(Long id);
    void save(Order order);
}

👉 JPA Repository랑 개념 동일

5) 서비스 (Domain Service)

언제 사용?

특정 엔티티에 속하지 않는 로직


class PaymentService {
    void pay(Order order) { ... }
}

6) 유비쿼터스 언어 (Ubiquitous Language)

개념

개발자 + 기획자가 동일한 용어 사용

예

“주문 취소 요청”

“환불 승인”

👉 코드에도 그대로 반영

4️⃣ DDD 구조 (Spring 기준)

1) 일반 구조 vs DDD 구조

❌ 기존 구조


controller
service
repository

✅ DDD 구조


domain
 ├─ entity
 ├─ value
 ├─ repository
 └─ service

application
 └─ service (유스케이스)

infrastructure
 └─ db, jpa

presentation
 └─ controller

2) 핵심 포인트

domain → 핵심 로직

application → 흐름 제어

infrastructure → 기술

presentation → API

5️⃣ 실무 예시 (중요)

💡

예약 취소 → 사장 승인 → 환불

❌ 일반적인 코드


// Service에 다 몰림
public void cancel(Long reservationId) {
    // 상태 변경
    // 환불 처리
    // 알림
}

👉 유지보수 지옥

✅ DDD 방식

Entity


class Reservation {
    void requestCancel() {
        this.status = "CANCEL_REQUEST";
    }
}

Domain Service


class RefundService {
    void refund(Reservation reservation) { ... }
}

Application Service


class ReservationAppService {
    void cancel(Long id) {
        Reservation r = repository.findById(id);
        r.requestCancel();
    }
}

👉 역할 분리됨:

Entity → 상태 변경

Service → 비즈니스 처리

Application → 흐름 제어

6️⃣ DDD의 장점 / 단점

✅ 장점

복잡한 비즈니스에 강함

유지보수 쉬움

협업 효율 ↑

코드 의미가 명확

❌ 단점

학습 난이도 높음

초기 설계 비용 큼

작은 프로젝트에는 오버엔지니어링

7️⃣ 한 줄 핵심 정리

👉 DDD는 “비즈니스 개념을 그대로 코드에 반영해서 복잡도를 관리하는 설계 방식”

Contents

MSA

4. DDD (도메인 주도 개발)

박은서

May 01, 2026

Contents

1. DDD (Domain Driven Design, 도메인 주도 개발)

1️⃣ DDD란?

1) 정의

도메인(업무 영역)을 중심으로 설계를 하는 개발 방법론

기술이 아니라 비즈니스 로직 중심으로 설계하는 것이 핵심

“코드를 기술 기준이 아니라, 업무(비즈니스) 기준으로 나누자”

2) 도메인이란?

소프트웨어가 해결하려는 업무 영역

예시

쇼핑몰 → 주문, 결제, 배송
은행 → 계좌, 송금, 이자

2️⃣ 왜 DDD를 사용하는가?

1) 기존 문제점 (CRUD 중심 개발)

Controller → Service → Repository 구조만 있음

비즈니스 로직이 Service에 몰림

문제

코드가 점점 복잡해짐
유지보수 어려움
협업 시 의미 전달 어려움

2) DDD의 해결 방향

업무 개념을 코드에 그대로 반영

개발자 ↔ 기획자 간 언어 통일

핵심 키워드

도메인 중심
의미 있는 코드 구조
복잡도 관리

3️⃣ 핵심 개념 (필수)

1) 엔티티 (Entity)

특징

고유 식별자(ID)가 있음

상태가 변해도 같은 객체


class Order {
    Long id;
    String status;
}

👉 주문 상태는 바뀌지만 같은 주문

2) 값 객체 (Value Object)

특징

값 자체가 의미

불변(immutable)

equals로 비교


class Address {
    String city;
    String street;
}

👉 주소는 ID보다 값이 중요

3) 애그리거트 (Aggregate)

개념

관련 객체를 하나의 묶음으로 관리

중심이 되는 객체 → Aggregate Root


Order (Root)
 ├─ OrderItem
 └─ Address

👉 외부에서는 Order만 접근 가능

필요한 이유

데이터 무결성 유지

트랜잭션 경계 설정

4) 리포지토리 (Repository)

역할

DB 접근 추상화


interface OrderRepository {
    Order findById(Long id);
    void save(Order order);
}

👉 JPA Repository랑 개념 동일

5) 서비스 (Domain Service)

언제 사용?

특정 엔티티에 속하지 않는 로직


class PaymentService {
    void pay(Order order) { ... }
}

6) 유비쿼터스 언어 (Ubiquitous Language)

개념

개발자 + 기획자가 동일한 용어 사용

예

“주문 취소 요청”

“환불 승인”

👉 코드에도 그대로 반영

4️⃣ DDD 구조 (Spring 기준)

1) 일반 구조 vs DDD 구조

❌ 기존 구조


controller
service
repository

✅ DDD 구조


domain
 ├─ entity
 ├─ value
 ├─ repository
 └─ service

application
 └─ service (유스케이스)

infrastructure
 └─ db, jpa

presentation
 └─ controller

2) 핵심 포인트

domain → 핵심 로직

application → 흐름 제어

infrastructure → 기술

presentation → API

5️⃣ 실무 예시 (중요)

💡

예약 취소 → 사장 승인 → 환불

❌ 일반적인 코드


// Service에 다 몰림
public void cancel(Long reservationId) {
    // 상태 변경
    // 환불 처리
    // 알림
}

👉 유지보수 지옥

✅ DDD 방식

Entity


class Reservation {
    void requestCancel() {
        this.status = "CANCEL_REQUEST";
    }
}

Domain Service


class RefundService {
    void refund(Reservation reservation) { ... }
}

Application Service


class ReservationAppService {
    void cancel(Long id) {
        Reservation r = repository.findById(id);
        r.requestCancel();
    }
}

👉 역할 분리됨:

Entity → 상태 변경

Service → 비즈니스 처리

Application → 흐름 제어

6️⃣ DDD의 장점 / 단점

✅ 장점

복잡한 비즈니스에 강함

유지보수 쉬움

협업 효율 ↑

코드 의미가 명확

❌ 단점

학습 난이도 높음

초기 설계 비용 큼

작은 프로젝트에는 오버엔지니어링

7️⃣ 한 줄 핵심 정리

👉 DDD는 “비즈니스 개념을 그대로 코드에 반영해서 복잡도를 관리하는 설계 방식”

Contents