클린 아키텍처는 소프트웨어 시스템을 구성하는 다양한 계층들을 명확하게 구분하여, 유지보수성과 테스트 용이성을 극대화하는 아키텍처 패턴입니다.
로버트 C. 마틴(Robert C. Martin, Uncle Bob)이 제안했으며, 의존성 규칙(Dependency Rule)에 따라 안쪽 계층이 바깥 계층에 의존하지 않도록 설계됩니다.
주요 목표
- 변경에 강한 구조
- 테스트 용이성 향상
- 비즈니스 로직의 독립성 확보
- 의존성 역전(DIP)을 통한 유연한 설계
클린 아키텍처의 계층 구성
+-------------------------+
| Frameworks & UI | ← 외부 시스템, UIKit, SwiftUI 등
+-------------------------+
↓
+-------------------------+
| Interface Adapter | ← ViewModel, Controller, Presenter
+-------------------------+
↓
+-------------------------+
| Application Business | ← UseCase
+-------------------------+
↓
+-------------------------+
| Enterprise Business | ← Entity (도메인 모델)
+-------------------------+계층별 역할
1. Entity (도메인 모델)
- 핵심 비즈니스 규칙을 표현
- 애플리케이션 전반에서 재사용 가능
- 외부와 완전히 독립적
2. Use Case (Application Business)
- Entity를 활용하여 앱의 구체적인 기능을 정의
- 애플리케이션의 구체적인 요구사항 처리
3. Interface Adapter
- 외부 입력/출력을 내부 구조에 맞게 변환
- ViewModel, Controller, Presenter 등이 포함됨
- Use Case를 호출하고 데이터를 포맷팅하여 View에 전달
4. Frameworks & Drivers
- UI, 데이터베이스, 네트워크 등 외부 기술적 요소 포함
- 의존성 주입(DI)을 통해 안쪽 계층에 주입됨
의존성 규칙 (Dependency Rule)
- 의존성은 반드시 안쪽 계층을 향해야 합니다.
- 안쪽 계층은 바깥 계층의 존재를 알지 못해야 하며, 인터페이스를 통해 접근해야 합니다.
장점
- 테스트 용이성: UseCase, Entity를 독립적으로 테스트 가능
- 유연성: UI, DB, 네트워크 등을 쉽게 교체 가능
- 유지보수성: 변경의 영향도를 최소화
- 비즈니스 로직의 재사용성 확보
단점
- 초기 설계 복잡도 상승
- 계층 간 interface 설계 및 DI 처리에 대한 부담
- 작은 프로젝트에는 과도한 구조일 수 있음
iOS에서의 적용 예
- Entity: User, Product 등 도메인 모델
- UseCase: LoginUseCase, FetchProductUseCase
- Interface Adapter: ViewModel, Presenter
- Frameworks: UIKit, Alamofire, CoreData 등
결론
클린 아키텍처는 장기적인 프로젝트에서 유지보수성과 테스트 효율을 극대화하기 위한 설계 방법입니다.
비즈니스 로직을 외부 프레임워크나 UI로부터 격리시켜 독립성과 유연성을 확보할 수 있습니다.
iOS Dev