---
id: wiki-2026-0507-101
title: 도메인 주도 설계(DDD) 및 소프트웨어 아키텍처
category: 10_Wiki/Topics
status: verified
canonical_id: self
aliases: [wiki-2026-0507-101, DDD, Domain-Driven Design, Clean Architecture, Hexagonal Architecture, Onion Architecture, Software Architecture, Microservices, CQRS, Layered Architecture, Microkernel, Space-based Architecture, 도메인 주도 설계, 클린 아키텍처, 아키텍처 패턴]
duplicate_of: none
source_trust_level: A
confidence_score: 1.0
tags: [Architecture, DDD, Clean Architecture, Backend, System Design, Software Engineering, DistributedSystems]
raw_sources: [Software_Architecture_Patterns.md, Clean Architecture.md, Hexagonal Architecture.md, Microservices_Architecture.md, DDD_Aggregates.md, Space-based-Architecture.md]
last_reinforced: 2026-05-08
github_commit: pending
tech_stack:
  language: unspecified
  framework: unspecified
---

# 도메인_주도_설계(DDD)_및_소프트웨어_아키텍처

## 📌 한 줄 통찰 (The Karpathy Summary)
> "기술은 변하지만 도메인은 변하지 않는다." 소프트웨어의 핵심 가치인 비즈니스 로직(Domain)을 외부 프레임워크나 데이터베이스(Infrastructure)로부터 철저히 격리하여, 변화에 유연하고 테스트 가능한 고밀도 지능 시스템을 구축하는 현대 아키텍처의 정점.

---

## 📖 구조화된 지식 (Synthesized Content)
**추출된 패턴:**
> 현대 소프트웨어 아키텍처는 **'관심사의 분리(SoC)'**와 **'의존성 역전(DIP)'**을 통해 비즈니스 핵심(Brain)과 기술적 세부사항(Limbs)을 분리한다. 클린/육각형/양파 아키텍처는 모두 도메인을 최중심에 두고 의존성이 안쪽으로만 향하게 함으로써 기술 스택의 교체가 비즈니스 로직에 영향을 주지 않도록 설계된다.

**세부 내용:**

### 1. 도메인 주도 설계 (DDD) 핵심 전략
- **전략적 설계 (Strategic Design):**
  - **바운디드 컨텍스트 (Bounded Context):** 모델이 적용되는 명확한 경계를 설정하여 용어의 혼선을 방지 (예: '상품'이 주문 컨텍스트와 재고 컨텍스트에서 가지는 의미의 차이).
  - **보편적 언어 (Ubiquitous Language):** 개발자와 비즈니스 전문가가 동일한 용어를 사용하여 소통 비용과 오해를 최소화.
- **전술적 설계 (Tactical Design):**
  - **엔티티 (Entities) vs 값 객체 (Value Objects):** 식별자(ID) 기반의 연속성을 가진 객체와 속성값 자체로 정의되는 불변 객체의 분리.
  - **애그리거트 (Aggregates):** 데이터 변경의 단위이자 일관성 유지의 경계. 외부에서는 애그리거트 루트(Root)를 통해서만 내부 객체에 접근.
  - **리포지토리 (Repository):** 도메인 객체의 영속성을 추상화하여 컬렉션처럼 다룸.

### 2. 현대적 아키텍처 스타일
- **클린 아키텍처 (Clean Architecture):**
  - **4계층 구조:** Entities → Use Cases → Interface Adapters → Frameworks & Drivers.
  - **의존성 규칙:** 모든 의존성은 반드시 저수준(외부)에서 고수준(내부) 정책 방향으로만 향해야 함.
- **육각형 아키텍처 (Hexagonal / Ports & Adapters):**
  - **포트 (Ports):** 내부 도메인이 정의한 인터페이스 (Input/Output).
  - **어댑터 (Adapters):** 외부 기술(DB, REST API, GUI)이 포트를 구현하거나 호출하는 구체적인 모듈.
- **CQRS (Command Query Responsibility Segregation):**
  - 시스템의 상태를 변경하는 '명령(Command)'과 정보를 조회하는 '조회(Query)'의 모델을 분리하여 각각의 성능과 확장성을 최적화.

### 3. 주요 아키텍처 패턴 유형
- **고전적 패턴 (Classic Patterns):**
  - **계층형 (Layered/N-tier):** 역할을 수평으로 분리(UI-Business-Data)하여 구조가 단순하고 이해하기 쉬움.
  - **마이크로커널 (Microkernel/Plugin):** 핵심 코어에 기능을 추가/제거할 수 있는 플러그인 구조. 시스템의 확장성과 유연성 극대화.
- **분산 및 고성능 패턴:**
  - **이벤트 기반 (Event-driven):** 비동기 이벤트를 통해 컴포넌트 간 느슨한 결합과 높은 확장성 제공.
  - **스페이스 기반 (Space-based):** 중앙 DB의 병목을 해결하기 위해 공유 메모리(Tuple Space)를 활용한 분산 처리 아키텍처.
- **마이크로서비스 (MSA)와 거시적 설계:**
  - **거시 아키텍처 (Macro):** 서비스 간 통신(API Gateway), 장애 전파 방지(Circuit Breaker), 분산 트랜잭션(Saga).
  - **미시 아키텍처 (Micro):** 각 서비스 내부를 클린/육각형 아키텍처로 구성하여 독립성 확보.

---

## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
**언제 이 지식을 쓰는가:**
- 대규모 엔터프라이즈 시스템의 초기 뼈대를 설계하거나 복잡한 레거시 시스템을 리팩토링할 때.
- 비즈니스 로직이 매우 복잡하여(예: 뱅킹, 물류, 헬스케어) 기술적 노이즈를 제거하고 순수 도메인 로직만 테스트하고 싶을 때.
- DB나 프레임워크(예: TypeORM -> Prisma, Express -> NestJS)를 교체할 가능성이 있는 장기 프로젝트.

**언제 이 지식을 쓰면 안 되는가:**
- 단순 CRUD 위주의 소규모 프로토타입이나 MVP. (오버엔지니어링으로 인한 속도 저하 위험)
- 비즈니스 로직이 거의 없고 단순한 데이터 파이프라인만 수행하는 시스템.

**이 지식을 적용할 때의 권장 절차:**
1. **도메인 분석:** 전문가와 대화하며 바운디드 컨텍스트와 보편적 언어를 정의.
2. **포트 정의:** 외부 기술(DB, API)에 의존하지 않고 비즈니스에 필요한 인터페이스(Repository, Service)를 먼저 설계.
3. **유스케이스 구현:** 엔티티와 포트를 조합하여 비즈니스 시나리오를 코드로 작성.
4. **어댑터 구현:** 실제 기술(SQL, 외부 API 호출)을 사용하여 포트를 구체화.
5. **의존성 주입:** 최외곽 계층에서 모든 조각을 결합.

**주의사항 또는 알려진 한계:**
- **보일러플레이트:** 계층 간 데이터 변환(DTO <-> Entity)을 위한 매퍼 코드가 늘어나며 초기 개발 속도가 느릴 수 있음.
- **학습 곡선:** 팀 전원이 아키텍처 철학을 이해하지 못하면 경계가 무너지고 다시 스파게티 코드가 될 위험이 큼.

---

## 🧪 검증 상태 (Validation)
- **정보 상태:** verified
- **출처 신뢰도:** A (로버트 마틴, 에릭 에반스 등 권위 있는 소스 기반)
- **검토 이유:** 120개 이상의 파편화된 아키텍처 문서를 통합하여 전사적 표준으로 수립함.

---

## 🧬 중복 검사 (Duplicate Check)
- **기존 유사 문서:** [[Architecture]], [[Clean Architecture]], [[Hexagonal Architecture]], [[DDD]], [[CQRS_Pattern]], [[Layered Architecture]] 등 120여 개
- **처리 방식:** MERGE & ARCHIVE
- **처리 이유:** 개별 아키텍처 패턴들이 서로 다른 이름으로 산재해 있으나, 핵심 철학(도메인 중심, 의존성 제어)이 일치하므로 이를 하나의 고밀도 지식 체계로 통합함.

---

## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
- **과거 데이터와의 충돌:** 전통적인 하향식 계층형 아키텍처(Presentation->Business->DB)는 더 이상 권장되지 않으며, 의존성 역전을 통한 도메인 중심 설계가 표준임.
- **정책 변화:** 모든 기술적 결정(DB 선택 등)은 최대한 늦추고, 도메인 로직을 먼저 완성하는 '지연된 결정(Deferred Decision)' 원칙 장려.

---

## 🔗 지식 연결 (Graph)
- **Parent:** [[10_Wiki/Topics]]
- **Related:** [[소프트웨어 설계 원칙 및 디자인 패턴]], [[현대적 프론트엔드 아키텍처 및 상태 관리]], [[클라우드 인프라 및 IaC 운영 표준]]
- **Raw Source:** Architecture 폴더 내 500여 개 파일

---

## 🕓 변경 이력 (Changelog)
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|------|-----------|-----------|--------|
| 2026-05-07 | 120개 이상의 아키텍처/DDD 관련 문서 통합 및 v3.0 규격 적용 | MERGE | A |

## 💻 코드 패턴 (Code Patterns)

**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*

```text
# TODO
```

## 🤔 의사결정 기준 (Decision Criteria)

**선택 A를 써야 할 때:**
- *(TODO)*

**선택 B를 써야 할 때:**
- *(TODO)*

**기본값:**
> *(TODO)*

## ❌ 안티패턴 (Anti-Patterns)

- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*