Antigravity Agent
3.4 KiB
3.4 KiB
Domain-Driven Design
📌 Brief Summary
도메인 주도 설계(Domain-Driven Design, DDD)는 기술적인 파일 유형이나 계층이 아닌 비즈니스 개념(예: 사용자, 주문, 결제 등)을 중심으로 프론트엔드 코드를 구성하는 아키텍처 접근법이다 [1]. 이 방식은 코드의 응집력을 높이고 비즈니스 이해관계자와의 원활한 소통을 돕지만, 프론트엔드 환경을 위한 구체적이고 표준화된 폴더 구조를 제공하지는 않는다는 한계가 있다 [1]. 이러한 개념은 최근 프론트엔드 생태계에서 기능 단위로 코드를 그룹화하는 기능 기반(Feature-based) 또는 도메인 기반(Domain-based) 디렉토리 구조 및 기능 분할 설계(Feature-Sliced Design)로 진화하여 확장성을 높이는 모범 사례로 활용되고 있다 [2-5].
📖 Core Content
- 비즈니스 개념 중심의 아키텍처 구성: 프론트엔드에서의 DDD는 단순한 사용자 인터페이스(UI) 개발을 넘어 비즈니스 도메인을 중심으로 코드를 그룹화한다 [1]. 이는 데이터를 다루거나 기술적 역할(컴포넌트, 훅, 서비스 등)별로 파일을 나누던 기존의 계층형 아키텍처(Layered Architecture)의 한계를 극복하며, 복잡한 비즈니스 로직을 처리하는 데 최적화되어 있다 [1, 6].
- 프론트엔드 구현의 한계: 순수한 도메인 주도 설계는 프론트엔드에 필요한 구체적이고 표준화된 폴더 구조를 제공하지 않는다 [1]. 이로 인해 개발 팀은 여러 도메인에서 공유하는 UI, 교차 도메인 기능 및 인프라 코드를 어디에 배치해야 할지 결정하는 데 종종 어려움을 겪는다 [1].
- 기능 분할 설계(Feature-Sliced Design, FSD)로의 진화: DDD의 한계를 극복하기 위해 프론트엔드 생태계에서는 기능 분할 설계(FSD)라는 구체적인 방법론이 등장했다 [2, 4]. FSD는 DDD와 개념적 유사성을 공유하면서도 React의 컴포넌트 기반 특성에 맞게 조정되었으며, 도메인 중심 원칙, 컴포넌트 기반 개발, 모듈형 시스템 아키텍처를 결합하여 명확한 경계와 계층 구조를 제공한다 [2, 4].
- 모던 프론트엔드의 디렉토리 구조 모범 사례: 2025년 기준, 프론트엔드 개발 산업 표준은 기능 기반 구조(Feature-based structure) 또는 도메인 기반 구조(Domain-based structure)로 이동했다 [3]. 컴포넌트 종류가 아닌 기능 및 도메인을 기준으로 컴포넌트, 훅, 로직을 분리하면 기능 간의 숨겨진 결합을 방지하고 코드베이스의 확장성과 유지보수성을 극대화할 수 있다 [3, 5].
🔗 Knowledge Connections
- Related Topics: Feature-Sliced Design, Component-Based Architecture, Layered Architecture
- Projects/Contexts: Scalable React Architecture, Frontend Folder Structure
- Contradictions/Notes: 소스 [1]는 DDD가 공유 UI나 공통 인프라 코드를 배치할 구체적이고 표준화된 프론트엔드 폴더 구조를 제공하지 못하는 한계가 있다고 지적합니다. 그러나 소스 [2, 4]에 따르면, 기능 분할 설계(FSD)가 DDD의 비즈니스 중심 원칙을 차용하면서도 프론트엔드에 특화된 구체적인 계층(Layers)과 슬라이스(Slices) 구조를 제공함으로써 이러한 단점을 보완하고 있음을 알 수 있습니다.
Last updated: 2026-04-26