# [[Domain-Driven Design (DDD)|Domain-Driven Design (DDD)]]

## 📌 Brief Summary
Domain-Driven Design (DDD)은 제한된 컨텍스트(bounded contexts)와 보편적 언어(ubiquitous language)와 같은 유용한 개념을 도입하는 소프트웨어 설계 방법론입니다 [1]. 프론트엔드 개발 팀은 종종 이러한 추상적인 개념을 실용적이고 유지보수 가능한 파일 시스템으로 변환하는 데 어려움을 겪습니다 [1]. 그러나 Feature-Sliced Design(FSD)과 같은 아키텍처 방법론을 활용하면 DDD의 개념을 도메인에 맞게 구체적인 프로젝트 구조로 구현하여 확장성 있는 프론트엔드를 구축할 수 있습니다 [1].

## 📖 Core Content
* **프론트엔드에서의 DDD 적용 한계:** DDD는 제한된 컨텍스트와 보편적 언어 등 훌륭한 아이디어를 제공하지만, 프론트엔드 팀들은 종종 이러한 추상적인 개념을 실용적인 디렉토리나 파일 시스템으로 해석하고 구현하는 데 어려움을 겪습니다 [1].
* **FSD를 통한 DDD 보완:** Feature-Sliced Design (FSD) 아키텍처는 DDD의 추상적인 개념을 구체적인 프로젝트 구조로 매핑하여 이러한 문제를 해결합니다 [1]. 
* **도메인 개념의 구조화 (Entities & Features):** FSD 구조에서 `entities/` 계층은 "User", "Product", "Order"와 같은 핵심 비즈니스 도메인 개념과 그에 따른 UI 및 상태(state) 표현을 담당합니다 [1, 2]. `features/` 계층은 사용자에게 가치를 제공하는 기능(예: 장바구니 담기, 결제 처리)을 포함하며, `shared/`는 재사용 가능한 UI 원형들을 보관합니다 [1, 2].
* **가시적인 도메인 경계:** 이러한 디렉토리 구조화를 통해 도메인의 경계가 단순히 문서상에만 존재하는 것이 아니라, 코드의 import 경로와 디렉토리에서 명확하게 시각화됩니다 [1].
* **모듈러 모놀리스(Modular Monolith)와의 연계:** 프론트엔드에서 수직적 슬라이스(Vertical Slice)나 모듈러 모놀리스 아키텍처를 채택할 때, 라우트, API, 테이블 등을 아우르는 엔드투엔드(end-to-end) 도메인 인터페이스를 정의할 수 있습니다 [3]. 도메인 간 워크플로우가 교차하는 경우 도메인 이벤트(domain events)를 활용하는 내부 이벤트 버스를 구성하여 결합도를 낮출 수 있습니다 [4].

## 🔗 Knowledge Connections
- **Related Topics:** [[Feature-Sliced Design (FSD)|Feature-Sliced Design (FSD)]], Modular Monolith
- **Projects/Contexts:** [[Scalable Frontend Architecture|Scalable Frontend Architecture]]
- **Contradictions/Notes:** 소스에서는 프론트엔드 환경에서 DDD를 단독으로 적용하면 개념이 너무 추상적이어서 실패하기 쉬우며, 이를 실질적인 파일 시스템으로 변환해주는 FSD와 같은 구체적인 아키텍처 패턴의 도움이 필수적이라고 강조합니다 [1].

---
*Last updated: 2026-04-26*