40 lines
2.6 KiB
Markdown
40 lines
2.6 KiB
Markdown
---
|
|
id: P-REINFORCE-AUTO-WIKI-ARCH-004
|
|
category: "10_Wiki/💡 Topics/02_Architecture_Principles"
|
|
confidence_score: 0.95
|
|
tags: [architecture, clean-architecture, layering, decoupling, domain-driven-design, p-reinforce]
|
|
last_reinforced: 2026-05-01
|
|
---
|
|
|
|
# [[Clean Architecture]]
|
|
|
|
## 📌 한 줄 통찰 (The Karpathy Summary)
|
|
> "비즈니스 로직(Domain)을 중심에 두고 UI, DB, 프레임워크와 같은 외부 세부 사항을 주변부로 밀어내어, 외부 기술의 변화가 시스템의 핵심 논리에 영향을 주지 않도록 격리하는 계층화 아키텍처의 정수."
|
|
|
|
## 📖 구조화된 지식 (Synthesized Content)
|
|
클린 아키텍처는 소프트웨어의 생존 기간을 늘리고 기술 부채를 제어하기 위한 거시적 설계 패턴입니다.
|
|
|
|
1. **의존성 규칙 (The Dependency Rule)**:
|
|
* 모든 의존성은 안쪽(도메인/엔티티)을 향해야 합니다.
|
|
* 내부 계층은 외부 계층(DB, Web, UI)에 대해 아무것도 몰라야 하며, 인터페이스를 통해서만 소통합니다.
|
|
2. **계층화 구조**:
|
|
* **Entities**: 핵심 비즈니스 규칙 및 데이터 모델.
|
|
* **Use Cases**: 애플리케이션 고유의 비즈니스 규칙(흐름 제어).
|
|
* **Interface Adapters**: 데이터 변환 레이어 (Controller, Presenter, Gateway).
|
|
* **Frameworks & Drivers**: DB, 프레임워크, 외부 API 등 기술적 세부 사항.
|
|
3. **장점**:
|
|
* 프레임워크 독립성: UI나 DB 프레임워크를 교체해도 비즈니스 로직은 수정할 필요가 없습니다.
|
|
* 테스트 용이성: 외부 요소 없이 핵심 로직만 독립적으로 단위 테스트가 가능합니다.
|
|
|
|
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
|
- **보일러플레이트의 증가**: 코드의 격리를 위해 다수의 인터페이스와 데이터 변환 객체(DTO)가 필요하게 되어 코드량이 늘어납니다. 프로젝트의 규모가 작을 때는 MVC보다 비효율적일 수 있습니다.
|
|
- **학습 곡선**: 계층 간 경계를 엄격히 지키는 설계 철학을 팀 전체가 공유하고 준수하는 데 높은 수준의 컨센서스와 코드 리뷰 역량이 요구됩니다.
|
|
|
|
## 🔗 지식 연결 (Graph)
|
|
- [[SOLID Principles]]: 각 계층 내부 설계를 지탱하는 원칙들.
|
|
- [[Domain-Driven Design (DDD)]]: 도메인 중심 설계 사상과의 시너지.
|
|
- [[Dependency Inversion Principle (DIP)]]: 계층 간 통신을 가능하게 하는 핵심 기술.
|
|
- [[Software Architecture Patterns]]: MVC, Hexagonal 아키텍처 등과의 비교.
|
|
- [[Over-engineering]]: 패턴의 맹목적 적용 시 경계해야 할 부작용.
|
|
---
|