Antigravity Agent
3.2 KiB
3.2 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 |
|
A | 1.0 |
|
|
2026-05-02 |
도메인 주도 설계 (Domain-Driven Design, DDD)
1. 개요
Domain-Driven Design(DDD)은 소프트웨어가 실제 비즈니스 로직과 규칙을 정확히 반영하도록 핵심 비즈니스 도메인(판매, 물류, 금융 등)을 모델링하는 데 집중하는 설계 철학이다. 기술적 세부 사항보다는 비즈니스의 복잡성을 해결하는 데 초점을 맞추며, 도메인 전문가와 개발자 간의 긴밀한 협업을 전제로 한다.
2. 주요 개념 및 구성 요소
- 전략적 설계 (Strategic Design):
- 보편적 언어 (Ubiquitous Language): 팀 전체가 공유하는 공통의 비즈니스 용어 체계.
- 제한된 컨텍스트 (Bounded Context): 모델이 적용되는 명확한 경계. 컨텍스트마다 용어의 의미가 다를 수 있음을 인정.
- 전술적 설계 (Tactical Design):
- 엔티티 (Entity): 고유한 식별자를 통해 정체성이 유지되는 객체.
- 값 객체 (Value Object): 속성값 자체로 정의되며 불변성을 가지는 객체.
- 애그리게이트 (Aggregate): 데이터 변경의 단위로 묶인 객체들의 집합.
- 리포지토리 (Repository): 애그리게이트의 영속성을 관리하는 인터페이스.
3. 실전 아키텍처 결합
- 육각형 아키텍처와의 조화: 육각형 아키텍처는 도메인을 보호하는 '구조(Structure)'를 제공하고, DDD는 그 내부의 '내용(Content)'을 채우는 방식으로 결합된다.
- 기술적 격리: 도메인 엔티티는 프레임워크 의존성(예: JPA 어노테이션)이 없는 순수 객체(POJO)로 유지하여 비즈니스 로직의 순수성을 보존한다.
4. 트레이드오프 및 주의사항
- 장점: 비즈니스 요구사항과 코드의 일치, 유지보수성 향상, 복잡한 로직의 체계적 관리.
- 단점: 높은 초기 설계 비용 및 학습 곡선, 단순한 CRUD 시스템에 적용 시 오버엔지니어링 위험.
- 테스트 전략: 도메인 로직 검증 시 과도한 모킹(Mocking)을 지양하고, 실제 동작을 담보하는 가짜 객체나 인메모리 테스트 권장.
5. 지식 연결 (Related)
- Bounded_Context: 도메인 모델의 경계를 설정하는 전략적 도구.
- Ubiquitous_Language: 협업과 모델링의 기초가 되는 공통 언어.
- Hexagonal_Architecture: DDD 모델을 외부 기술로부터 격리하는 아키텍처 프레임워크.
🧪 검증 상태 (Validation)
- 정보 상태: 검증 완료 (Verified)
- 출처 신뢰도: A
- 검토 이유: 비즈니스 가치를 소프트웨어 구조로 전환하기 위한 가장 강력한 설계 패러다임 정립.