로버트 C. 마틴이 만든 소프트웨어 관심사를 계층별로 분리하는 소프트웨어 디자인 철학.
Use Case
를 중심으로 설계..!!!!
주요 원칙
의존성이 외부 -> 내부
방향으로 존재한다.
( 내부 계층은 외부 계층을 알 수 없다. )
외부 계층에 존재하는 변수, 함수 및 클래스는 내부에서 사용할 수 없다.
데이터 형식도 Layer
간에 별도로 유지하는 것이 좋다.
장점
구성 요소
Entities
Use Cases
Interface Adapters
-Entites나 Use Cases로부터 얻은 데이터를 가공하는 Layer다.
-데이터를 Layer에 맞는 형식으로 변환한다.
-Presenter, View, Viewmodel, Controller가 여기에 속한다.
-비즈니스 로직과 프레임워크 코드를 연결
Frameworks와 Drivers
-Activity, Fragment, Intent 전달, 데이터베이스, Contents Provider, Retrofit과 같은 네트워크 관련된 프레임워크 코드가 포함된다.
Presentation Layer
Use case
를 실행한다.Domain Layer
에 의존성을 가진다.Domain Layer
비즈니스 로직을 포함한다.
가장 안쪽의 Layer
로 어떤 Layer
에 대해서도 의존성을 가지지 않는다. 오직 언어(Kotlin)에 대해서만 의존성을 가진다.
Entity
, Use case
, Repository Interface
를 포함한다.
Use case
는 data와 1개 이상의 Repository Interface를 받아 비즈니스 로직을 처리한다.
- Use Case
는 행동들의 최소 단위이다.
- Use Case
는 보통 1개의 행동을 담당하며 이름만 보고도 무슨 기능을 하는지 짐작 가능해야 한다.
Domain Layer가 Data Layer에 대해 의존성을 가지지 않기 위해선?
의존성 역전 법칙을 이용해 interface를 사용한 추상화를 적용한다.
Domain Layer는 Data Layer에 대한 의존성 회피를 위해 Repository를 추상화시켜 사용하고 있다.
Data Layer
Repository Implementation
, 1개 이상의 Data Source
, Mapper
(Mapper 대신 Interface 구현으로 대체 가능), Data Model
을 포함한다.Repository
는 다른 Data Source
들을 결합 / 조정한다.Domain Layer
에 의존성을 가진다.Data Source와 DataSourceImpl
Data Soruce 역시 의존성 역전 법칙을 적용해 추상화된다. Repository가 Data Source에 대해 의존성을 가지지 않게 한다. 따라서 Data Source가 변경되더라도 Repository에 대한 영향을 줄일 수 있다.