diff --git a/2024/12/2024-12-21_DDD/README.md b/2024/12/2024-12-21_DDD/README.md new file mode 100644 index 0000000..a7372d4 --- /dev/null +++ b/2024/12/2024-12-21_DDD/README.md @@ -0,0 +1,93 @@ +# Domain-Driven Design (DDD) + +오늘은 **Domain-Driven Design(DDD)** 에 대해 정리하려고 한다. 소프트웨어 개발에서 DDD는 복잡한 비즈니스 로직을 코드로 풀어내는 데 초점을 맞춘 설계 방법론이다. 도메인에 대한 깊은 이해를 기반으로 소프트웨어를 설계하며, 특히 다양한 도메인을 다루는 프로젝트에서 많이 사용된다. + +--- + +## 1. DDD란? + +DDD는 비즈니스 로직을 중심으로 소프트웨어를 설계하는 방법이다. Eric Evans가 제안한 이 방법론은 비즈니스와 개발 간의 긴밀한 협업과 소통을 중요하게 여긴다. + +### 핵심 개념 +- **Domain Model**: 소프트웨어에서 도메인의 핵심 개념을 코드로 표현한 것. +- **Ubiquitous Language**: 비즈니스 관계자와 개발자가 같은 용어로 소통하도록 돕는 언어. + +--- + +## 2. DDD의 주요 구성 요소 + +DDD를 적용할 때 사용하는 핵심 구성 요소를 살펴보자. + +### **1) Entity** +- 고유 식별자를 가진 객체로, 상태와 동작을 캡슐화한다. +- 예: `Order`, `Customer`. + +### **2) Value Object** +- 식별자 없이 속성 값으로 구분되며, 불변 객체로 설계하는 경우가 많다. +- 예: `Money`, `Address`. + +### **3) Aggregate** +- 관련 Entity와 Value Object를 묶어 일관성을 유지하는 단위. +- 예: `Order`는 여러 `OrderItem` 엔티티를 포함한 Aggregate로 동작한다. + +### **4) Domain Service** +- 특정 Entity에 속하지 않는 비즈니스 로직을 처리. +- 예: 배송 비용 계산, 결제 처리. + +### **5) Repository** +- 데이터베이스와 상호작용을 추상화하여 Aggregate를 저장하고 조회. +- 예: `OrderRepository`, `CustomerRepository`. + +### **6) Factory** +- 복잡한 객체 생성을 캡슐화하여 쉽게 생성. +- 예: 초기화된 엔티티 생성 메서드. + +--- + +## 3. DDD의 적용 방식 + +DDD는 도메인과 비즈니스 로직에 대한 깊은 이해가 필수적이다. 적용 방식을 몇 가지 정리해 보았다. + +### 1) Ubiquitous Language 도입 +- 비즈니스 관계자와 개발자가 도메인의 개념을 동일한 언어로 이해하도록 돕는다. +- 예: 고객(Customer)과 주문(Order)의 정의를 코드에 반영. + +### 2) Bounded Context 정의 +- 도메인을 Context로 나누어 설계하며, 각 Context는 독립적으로 작동하도록 한다. +- 예: 주문(Order) Context와 배송(Shipping) Context를 분리. + +### 3) Domain Model의 구현 +- Entity와 Value Object로 Domain Model을 작성하며, 복잡한 비즈니스 로직은 Domain Service로 관리. + +--- + +## 4. DDD의 장단점 + +### 장점 +- **복잡한 로직 관리**: 도메인을 중심으로 설계하므로 복잡한 로직을 쉽게 관리할 수 있다. +- **유지보수성 향상**: 코드와 비즈니스 로직 간의 간극을 줄여 변경 사항을 쉽게 반영. +- **비즈니스와의 협업 강화**: 같은 언어로 소통하므로 이해관계자 간의 협력이 원활해진다. + +### 단점 +- **초기 비용 부담**: 설계와 도메인 분석에 많은 시간과 노력이 필요하다. +- **기술적 난이도**: Aggregate, Event Sourcing 등 익숙하지 않은 개념이 포함된다. +- **단순한 프로젝트엔 비효율적**: CRUD 중심의 단순한 시스템에는 오히려 과도한 설계가 될 수 있다. + +--- + +## 5. 주의사항 + +1. **도메인의 복잡성을 제대로 이해하라** + - DDD는 복잡한 비즈니스 문제를 해결하는 데 적합하다. 단순한 프로젝트에는 다른 방법론이 더 효과적일 수 있다. + +2. **Bounded Context를 명확히 정의하라** + - Context 간의 경계가 불분명하면 설계 복잡도가 증가할 수 있다. + +3. **꾸준한 피드백과 개선이 필요하다** + - 도메인은 지속적으로 변화하며, 설계 역시 변화에 맞게 개선해야 한다. + +--- + +## 결론 + +DDD는 비즈니스 로직을 코드로 풀어내는 데 효과적이다. Domain 중심의 설계를 통해 복잡한 문제를 해결할 수 있지만, 적용에는 많은 준비와 학습이 필요하다. Domain과 비즈니스 요구사항에 대한 깊은 이해가 뒷받침될 때 DDD의 진가를 발휘할 수 있다. \ No newline at end of file