DDD 도메인 주도 설계 개념과 필요성 정리

1. DDD란?

DDD(Domain-Driven Design)는

비즈니스 도메인을 중심으로 소프트웨어를 설계하는 방법론이다.

👉 쉽게 말하면

“코드가 아니라, 비즈니스 자체를 기준으로 설계하자”

---

2. 도메인이란?

여기서 말하는 “도메인(Domain)”은

서비스가 해결하려는 문제 영역을 의미한다.

---

📌 예시 (쇼핑몰)

• 주문 (Order)

• 결제 (Payment)

• 회원 (User)

• 재고 (Stock)

👉 이 각각이 도메인이다

---

3. 왜 DDD가 필요한가?

프로젝트가 커질수록 이런 문제가 생긴다:

---

❌ 문제 상황

• 코드가 비즈니스와 따로 논다

• 어디서 무엇을 하는지 알기 어렵다

• 기능이 서로 얽혀 있음

• 유지보수 어려움

---

✅ DDD 목표

“코드 구조 = 비즈니스 구조”

---

즉,

OrderService → 주문 처리
PaymentService → 결제 처리

👉 이렇게 명확하게 나누는 것

---

4. 핵심 개념

DDD는 개념이 많지만 핵심만 잡으면 된다.

---

5. Ubiquitous Language (유비쿼터스 언어)

개발자와 기획자가 같은 용어를 사용하는 것

---

❌ 나쁜 예

• DB에는 tbl_user

• 코드에는 Member

• 기획서는 Customer

👉 혼란 발생

---

✅ 좋은 예

• 전부 User

👉 모두 같은 언어 사용

---

6. Bounded Context (경계된 컨텍스트)

DDD에서 가장 중요한 개념

---

개념

하나의 도메인이 독립적으로 의미를 가지는 영역

---

📌 예시

같은 "User"라도 다르게 쓰인다

• 주문 도메인 → 구매자

• 인증 도메인 → 로그인 사용자

👉 그래서 나눈다

User (Auth Context)
User (Order Context)

---

핵심

“같은 단어라도 컨텍스트에 따라 의미가 다르다”

---

7. Entity vs Value Object

---

✔ Entity

• 고유 식별자(ID)가 있음

• 상태가 변함

Order (주문)
User (사용자)

---

✔ Value Object

• 값 자체가 중요

• 불변(Immutable)

주소 (Address)
금액 (Money)

---

8. Aggregate (애그리거트)

👉 DDD 핵심 개념 중 하나

---

개념

관련된 객체들을 하나의 단위로 묶은 것

---

예시

Order
 ├─ OrderItem
 ├─ PaymentInfo

👉 이걸 하나의 Aggregate로 관리

---

Aggregate Root

• 대표 객체

Order ← Root

👉 외부에서는 Root만 접근

---

9. Repository

Aggregate를 저장/조회하는 인터페이스

---

역할

• DB 접근 추상화

• 도메인 중심 인터페이스 제공

---

OrderRepository.save(order);
OrderRepository.findById(id);

---

10. Domain Service

Entity로 처리하기 애매한 로직을 담당

---

예시

결제 승인 로직
주문 생성 로직

👉 특정 객체 하나에 속하지 않는 경우

---

11. DDD 구조 (레이어)

보통 이렇게 나눈다:

Presentation (Controller)
Application (Use Case)
Domain (핵심 비즈니스)
Infrastructure (DB, 외부 API)

---

핵심 포인트

Domain 레이어가 가장 중요

---

12. MSA와 DDD 관계

DDD는 MSA 설계할 때 거의 필수다.

---

왜?

MSA에서는 서비스를 나눠야 한다.

👉 기준이 필요

---

DDD가 기준 제공

Order Domain → Order Service
Payment Domain → Payment Service

👉 자연스럽게 서비스 분리 가능

---

13. DDD의 장점

🚀 1. 비즈니스 중심 설계

• 코드 이해 쉬움

---

🚀 2. 유지보수 용이

• 책임이 명확

---

🚀 3. MSA에 적합

• 서비스 분리 기준 제공

---

🚀 4. 협업 효율 증가

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

---

14. DDD의 단점

⚠️ 1. 학습 난이도 높음

• 개념 많음

---

⚠️ 2. 초기 설계 비용

• 시간 많이 듦

---

⚠️ 3. 과도한 설계 위험

👉 작은 프로젝트에는 과함

---

15. 언제 DDD를 써야 할까?

✔ 적합

• 복잡한 비즈니스 로직

• 대규모 서비스

• MSA 구조

---

❌ 부적합

• 간단한 CRUD 서비스

• 개인 프로젝트

---

16. 핵심 요약

DDD는

비즈니스 구조를 그대로 코드에 반영하는 설계 방법

---

🔥 한 줄 정리

DDD는 “코드를 비즈니스처럼 만들기 위한 방법”이다

---

👉 마무리

복잡한 시스템일수록 기술 중심 설계보다 도메인 중심 설계가 중요해진다. DDD는 단순한 설계 패턴이 아니라, 비즈니스와 코드를 연결하는 사고 방식이다.