Files
2nd/10_Wiki/Topics_Arch/Domain_Driven_Design.md
T

2.8 KiB

id, title, category, status, canonical_id, aliases, duplicate_of, source_trust_level, confidence_score, tags, raw_sources, last_reinforced, github_commit
id title category status canonical_id aliases duplicate_of source_trust_level confidence_score tags raw_sources last_reinforced github_commit
P-REINFORCE-WIKI-ARCH-DDD 도메인 주도 설계 (Domain-Driven Design, DDD) 10_Wiki/🏗️ Topics_Arch verified
DDD
Domain-Driven Design
바운디드 컨텍스트
A 1.0
Architecture
DDD
Ubiquitous_Language
Bounded_Context
Software_Design
Datacollector_Export_2026-05-02
2026-05-02

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

1. 개요

Domain-Driven Design(DDD)은 복잡한 비즈니스 로직을 소프트웨어의 중심에 두고, 기술 팀과 도메인 전문가 간의 협력을 통해 비즈니스 프로세스를 코드로 모델링하는 설계 접근 방식이다. '유비쿼터스 언어'와 '바운디드 컨텍스트'를 통해 시스템의 복잡성을 관리 가능한 수준으로 분해한다.

2. 전략적 설계 (Strategic Design)

  • 유비쿼터스 언어 (Ubiquitous Language): 개발자와 비즈니스 이해관계자가 공통으로 사용하는 공유 언어. 코드, 문서, 대화에 동일하게 적용됨.
  • 바운디드 컨텍스트 (Bounded Context): 특정 도메인 모델이 적용되는 논리적 경계. 각 컨텍스트는 독립적인 모델과 언어를 가짐.
  • 컨텍스트 매핑 (Context Mapping): 서로 다른 바운디드 컨텍스트 간의 관계와 통신 방식을 정의.

3. 전술적 설계 (Tactical Design)

  • Entities (엔티티): 고유한 식별자를 가지며 상태가 변할 수 있는 객체.
  • Value Objects (값 객체): 고유 식별자 없이 속성 값만으로 정의되는 불변 객체.
  • Aggregates (애그리거트): 데이터 일관성을 보장하기 위해 하나로 묶인 도메인 객체 군집. 애그리거트 루트를 통해서만 접근 가능.
  • Repositories: 애그리거트의 영속성을 관리하는 인터페이스.

4. 트레이드오프

  • 장점: 비즈니스 로직의 명확한 가시성, 유지보수성 향상, 유연한 아키텍처 확장(Microservices로의 전환 용이).
  • 단점: 설계 및 구현 복잡도 상승, 도메인 전문가와의 긴밀한 협업 비용 발생, 단순한 프로젝트에서는 오버헤드.

🧪 검증 상태 (Validation)

  • 정보 상태: 검증 완료 (Verified)
  • 출처 신뢰도: A
  • 검토 이유: 엔터프라이즈 급 소프트웨어 설계의 근간이 되는 DDD의 핵심 원칙 정립.