Fix: Restore unified Topics folder and reorganize specialized category folders
This commit is contained in:
Antigravity Agent
@@ -1,49 +1,68 @@
|
||||
---
|
||||
id: P-REINFORCE-WIKI-ARCH-DDD
|
||||
title: "도메인 주도 설계 (Domain-Driven Design, DDD)"
|
||||
category: Dev
|
||||
status: verified
|
||||
canonical_id: ""
|
||||
aliases: ["DDD", "Domain-Driven Design", "도메인 주도 개발", "전략적 설계"]
|
||||
duplicate_of: ""
|
||||
source_trust_level: A
|
||||
confidence_score: 1.0
|
||||
tags: ["DDD", "Architecture", "Software_Design", "Business_Logic", "Strategic_Design"]
|
||||
raw_sources: ["Datacollector_Export_2026-05-02"]
|
||||
last_reinforced: 2026-05-02
|
||||
github_commit: ""
|
||||
tags: [Architecture, Design Patterns, DDD, Modeling]
|
||||
title: Domain-Driven Design (DDD)
|
||||
description: 비즈니스 도메인의 복잡성을 해결하기 위해 기술과 비즈니스를 정렬하고 공통 언어를 기반으로 설계하는 방법론
|
||||
last_updated: 2026-05-02
|
||||
---
|
||||
|
||||
# [[도메인 주도 설계 (Domain-Driven Design, DDD)]]
|
||||
# Domain-Driven Design (DDD)
|
||||
|
||||
## 1. 개요
|
||||
Domain-Driven Design(DDD)은 소프트웨어가 실제 비즈니스 로직과 규칙을 정확히 반영하도록 핵심 비즈니스 도메인(판매, 물류, 금융 등)을 모델링하는 데 집중하는 설계 철학이다. 기술적 세부 사항보다는 비즈니스의 복잡성을 해결하는 데 초점을 맞추며, 도메인 전문가와 개발자 간의 긴밀한 협업을 전제로 한다.
|
||||
## 📌 Brief Summary
|
||||
**도메인 주도 설계(Domain-Driven Design, DDD)**는 소프트웨어 개발의 중심을 기술이 아닌 **비즈니스 도메인**에 두는 설계 접근 방식입니다. 에릭 에반스(Eric Evans)에 의해 정립된 이 방법론은 도메인 전문가와 개발자 간의 간극을 줄이기 위해 공통의 언어(**Ubiquitous Language**)를 구축하고, 시스템을 논리적 경계인 **바운디드 컨텍스트(Bounded Context)**로 나누어 관리 가능한 수준의 복잡성을 유지합니다.
|
||||
|
||||
## 2. 주요 개념 및 구성 요소
|
||||
- **전략적 설계 (Strategic Design)**:
|
||||
- **보편적 언어 (Ubiquitous Language)**: 팀 전체가 공유하는 공통의 비즈니스 용어 체계.
|
||||
- **제한된 컨텍스트 (Bounded Context)**: 모델이 적용되는 명확한 경계. 컨텍스트마다 용어의 의미가 다를 수 있음을 인정.
|
||||
- **전술적 설계 (Tactical Design)**:
|
||||
- **엔티티 (Entity)**: 고유한 식별자를 통해 정체성이 유지되는 객체.
|
||||
- **값 객체 (Value Object)**: 속성값 자체로 정의되며 불변성을 가지는 객체.
|
||||
- **애그리게이트 (Aggregate)**: 데이터 변경의 단위로 묶인 객체들의 집합.
|
||||
- **리포지토리 (Repository)**: 애그리게이트의 영속성을 관리하는 인터페이스.
|
||||
---
|
||||
|
||||
## 3. 실전 아키텍처 결합
|
||||
- **육각형 아키텍처와의 조화**: 육각형 아키텍처는 도메인을 보호하는 '구조(Structure)'를 제공하고, DDD는 그 내부의 '내용(Content)'을 채우는 방식으로 결합된다.
|
||||
- **기술적 격리**: 도메인 엔티티는 프레임워크 의존성(예: JPA 어노테이션)이 없는 순수 객체(POJO)로 유지하여 비즈니스 로직의 순수성을 보존한다.
|
||||
## 📖 Core Content
|
||||
|
||||
## 4. 트레이드오프 및 주의사항
|
||||
- **장점**: 비즈니스 요구사항과 코드의 일치, 유지보수성 향상, 복잡한 로직의 체계적 관리.
|
||||
- **단점**: 높은 초기 설계 비용 및 학습 곡선, 단순한 CRUD 시스템에 적용 시 오버엔지니어링 위험.
|
||||
- **테스트 전략**: 도메인 로직 검증 시 과도한 모킹(Mocking)을 지양하고, 실제 동작을 담보하는 가짜 객체나 인메모리 테스트 권장.
|
||||
### 1. 전략적 설계 (Strategic Design)
|
||||
비즈니스 문제를 큰 틀에서 분석하고 시스템의 경계를 정의합니다.
|
||||
* **유비쿼터스 언어 (Ubiquitous Language):** 도메인 전문가, 기획자, 개발자가 프로젝트 전반에서 사용하는 공통 어휘입니다. 이 언어는 문서, 대화뿐만 아니라 코드(클래스명, 메서드명)에도 그대로 반영되어야 합니다.
|
||||
* **바운디드 컨텍스트 (Bounded Context):** 유비쿼터스 언어가 적용되는 논리적인 경계입니다. 동일한 단어(예: '상품')라도 컨텍스트(주문 vs 배송)에 따라 그 의미와 모델이 다를 수 있음을 인정하고 격리합니다.
|
||||
* **컨텍스트 맵 (Context Map):** 서로 다른 바운디드 컨텍스트 간의 관계(협력, 의존 등)를 시각화한 지도입니다.
|
||||
|
||||
## 5. 지식 연결 (Related)
|
||||
- [[Bounded_Context]]: 도메인 모델의 경계를 설정하는 전략적 도구.
|
||||
- [[Ubiquitous_Language]]: 협업과 모델링의 기초가 되는 공통 언어.
|
||||
- [[Hexagonal_Architecture]]: DDD 모델을 외부 기술로부터 격리하는 아키텍처 프레임워크.
|
||||
### 2. 전술적 설계 (Tactical Design)
|
||||
바운디드 컨텍스트 내부의 구체적인 모델링 도구들을 제공합니다.
|
||||
* **엔티티 (Entities):** 식별자(ID)에 의해 정의되는 객체입니다. 속성이 변하더라도 식별자가 같다면 동일한 객체로 간주합니다.
|
||||
* **값 객체 (Value Objects):** 속성값 그 자체로 정의되는 객체입니다. 식별자가 없으며 보통 불변(Immutable) 상태로 관리됩니다.
|
||||
* **애그리거트 (Aggregates):** 데이터 변경의 단위로 취급되는 도메인 객체들의 군집입니다. 각 애그리거트는 '루트(Root)' 엔티티를 통해 외부와 소통하며 데이터 일관성을 보장합니다.
|
||||
* **도메인 서비스 (Domain Services):** 특정 엔티티나 값 객체에 속하기 어려운 비즈니스 로직을 처리하는 무상태(Stateless) 서비스입니다.
|
||||
* **리포지토리 (Repositories):** 애그리거트 루트를 영구 저장소에 저장하고 조회하기 위한 메커니즘을 제공합니다.
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
- **정보 상태**: 검증 완료 (Verified)
|
||||
- **출처 신뢰도**: A
|
||||
- **검토 이유**: 비즈니스 가치를 소프트웨어 구조로 전환하기 위한 가장 강력한 설계 패러다임 정립.
|
||||
---
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
|
||||
### ✅ Benefits
|
||||
* **비즈니스 정렬:** 기술적 구현이 실제 비즈니스 요구사항과 정확히 일치하게 됩니다.
|
||||
* **복잡성 관리:** 거대한 시스템을 독립적인 컨텍스트로 나누어 인지적 과부하를 줄입니다.
|
||||
* **유연성:** 각 도메인이 독립적으로 진화할 수 있어 변화에 빠르게 대응할 수 있습니다.
|
||||
|
||||
### ⚠️ Challenges
|
||||
* **높은 초기 비용:** 도메인 전문가와의 긴밀한 협업과 분석 과정에 많은 시간이 소요됩니다.
|
||||
* **설계 난이도:** 바운디드 컨텍스트의 경계를 잘못 설정할 경우, 시스템 간의 결합도가 높아져 더 큰 혼란을 야기할 수 있습니다.
|
||||
* **오버헤드:** 비즈니스 로직이 단순한 CRUD 앱에서는 구조적 복잡성만 높이는 과잉 엔지니어링이 될 수 있습니다.
|
||||
|
||||
---
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
|
||||
### Related Concepts
|
||||
* [[Bounded_Context]]: DDD의 핵심적인 격리 단위입니다.
|
||||
* [[Ubiquitous_Language]]: 팀 내 소통의 오류를 제거하는 기반 언어입니다.
|
||||
* [[Clean_Architecture]]: 도메인을 중앙에 두고 인프라를 격리하는 구조적 틀을 제공합니다.
|
||||
* [[Event_Storming]]: 비즈니스 흐름을 분석하여 DDD 모델을 도출하는 워크샵 기법입니다.
|
||||
|
||||
### Practical Application Contexts
|
||||
* **Microservices:** 바운디드 컨텍스트는 마이크로서비스를 나누는 가장 이상적인 기준점이 됩니다.
|
||||
* **Enterprise Systems:** 복잡한 비즈니스 규칙이 얽힌 대규모 금융, 이커머스 시스템의 필수 설계 사상입니다.
|
||||
|
||||
---
|
||||
|
||||
## 💡 Adjacent Topics
|
||||
* [[Microservices_Architecture]]: DDD의 전략적 설계를 통해 서비스 간 느슨한 결합을 구현합니다.
|
||||
* [[Layered_Architecture]]: 기술적 계층 분리와 도메인 중심 분리의 차이를 이해하는 비교군입니다.
|
||||
* [[Event_Driven_Architecture]]: 애그리거트 간의 상태 변경을 이벤트를 통해 전파하여 일관성을 유지합니다.
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-02*
|
||||
|
||||
Reference in New Issue
Block a user