2.6 KiB
2.6 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-CLEAN-ARCHITECTURE | 클린 아키텍처 (Clean Architecture) | 10_Wiki/🏗️ Topics_Arch | verified |
|
A | 1.0 |
|
|
2026-05-02 |
클린 아키텍처 (Clean Architecture)
1. 개요
클린 아키텍처(Clean Architecture)는 로버트 C. 마틴(Robert C. Martin)이 제안한 소프트웨어 설계 패턴으로, 도메인 중심 설계와 프레임워크 독립성을 핵심 원칙으로 삼는다. 시스템을 동심원 형태의 계층으로 나누고, 의존성의 방향을 항상 안쪽(도메인)으로만 향하게 하여 외부 기술 변화에 강건한 구조를 만든다.
2. 동심원 계층 구조
- Entities (엔티티): 가장 안쪽 원. 핵심 비즈니스 규칙을 담은 전사적 객체. 외부 변화에 가장 안정적임.
- Use Cases (유스케이스): 애플리케이션 특화 비즈니스 규칙. 엔티티를 조정하여 데이터 흐름을 오케스트레이션함.
- Interface Adapters (인터페이스 어댑터): 외부와 도메인 사이의 번역기. 컨트롤러, 프리젠터, 리포지토리 등이 포함됨.
- Frameworks & Drivers: 가장 바깥쪽 원. DB, 웹 프레임워크, UI 등 세부 사항. 언제든 교체 가능한 플러그인처럼 동작해야 함.
3. 핵심 원칙: 의존성 규칙 (Dependency Rule)
- 소스 코드 의존성은 반드시 **안쪽 원(고수준 정책)**으로만 향해야 한다.
- 안쪽 원은 바깥쪽 원에 대해 전혀 알지 못해야 하며, 바깥쪽 원의 함수, 클래스, 변수 등을 참조해서는 안 된다.
4. 트레이드오프
- 장점: 프레임워크 독립성, 테스트 용이성, UI/DB 독립성 확보.
- 단점: 단순한 CRUD 애플리케이션에서는 과도한 엔지니어링(Overkill) 및 보일러플레이트 코드 양산 가능성.
5. 지식 연결 (Related)
- Hexagonal_Architecture: 유사한 철학(포트와 어댑터)을 공유하는 아키텍처.
- Domain_Driven_Design: 엔티티와 Bounded Context를 정의하는 방법론.
- SOLID_Principles: 클린 아키텍처를 지탱하는 5대 설계 원칙.
🧪 검증 상태 (Validation)
- 정보 상태: 검증 완료 (Verified)
- 출처 신뢰도: A
- 검토 이유: 소프트웨어 아키텍처의 표준 모델로서의 정확성 확보.