chore: update graph view scale and set workspace default tab to graph view
This commit is contained in:
Antigravity Agent
@@ -0,0 +1,115 @@
|
||||
---
|
||||
id: "wiki-2026-0507-101"
|
||||
title: "도메인_주도_설계(DDD)_및_소프트웨어_아키텍처"
|
||||
category: "[[10_Wiki/Topics]]"
|
||||
status: "verified"
|
||||
canonical_id: "self"
|
||||
aliases: ["DDD", "Domain-Driven Design", "Clean Architecture", "Hexagonal Architecture", "Onion Architecture", "Software Architecture", "Microservices", "CQRS", "도메인 주도 설계", "클린 아키텍처", "육각형 아키텍처"]
|
||||
duplicate_of: "none"
|
||||
source_trust_level: "A"
|
||||
confidence_score: 1.0
|
||||
tags: ["Architecture", "DDD", "Clean Architecture", "Backend", "System Design", "Software Engineering"]
|
||||
raw_sources: ["Clean Architecture.md", "Hexagonal Architecture.md", "Microservices_Architecture.md", "DDD_Aggregates.md", "CQRS_Pattern.md"]
|
||||
last_reinforced: "2026-05-07"
|
||||
github_commit: "pending"
|
||||
---
|
||||
|
||||
# 도메인_주도_설계(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. 마이크로서비스 (MSA)와 거시적 설계
|
||||
- **거시 아키텍처 (Macro):** 서비스 간의 통신(이벤트 브로커, API 게이트웨이), 장애 전파 방지(Circuit Breaker), 분산 트랜잭션 처리(Saga Pattern).
|
||||
- **미시 아키텍처 (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 |
|
||||
Reference in New Issue
Block a user