클린 아키텍처
- 엔티티 : 가장 일반적인 비즈니스 규칙(재사용 가능한 로직)을 캡슐화, 외부의 무언가가 변경되어도 엔티티가 변경될 가능성은 낮음
- 유스케이스 : 특정 앱의 비즈니스 규칙, 엔티티로 들어오고 나가는 데이터 흐름을 조정, 변경사항이 엔티티에 영향을 줘서는 안되며 외부요소에서 발생한 변경에 영향을 받아서도 안됨
- 인터페이스 어댑터 : 일련의 어댑터들로 구성, 상위 계층(유스케이스)와 하위 계층(프레임워크 등)간의 중간다리 역할, 흔히 MVP, MVVM 같은 아키텍처가 여기에 속함
- 프레임워크, 드라이버 : App, DB, HTTP Client 등으로 구성 (코드 외 외부세계), 자주 쉽게 변경될 수 있는 부분, 일반적으로 이 영역에서 작성할 코드는 거의 없음
클린 아키텍처 사용시 장점
- 관심사의 분리 통해 유지보수 용이
- 시스템을 바꾸지 않고 코드를 유연하게 수정
- UI, 데이터베이스, 프레임워크 등의 독립성
- 테스트 용이성
동심원 내부의 화살표 방향으로 알 수 있듯 바깥원에서 안쪽원으로 의존하는 규칙을 갖는다. 즉, 안쪽원은 바깥원에 대한 정보를 몰라야 한다.
이러한 원칙을 지키기 위해 안드로이드에서는 계층별로 모듈을 분리하고 의존 관계를 설정할 수 있다.
일반적으로 다음과 같이 모듈을 나눌 수 있다.
- Presentation
- domain
- data
안드로이드에서는 엔티티를 다른 플랫폼과 사실상 공유하기 힘들다. 그러므로 domain이라는 모듈 아래 유스케이스와 엔티티를 통합하였다.
domain 모듈
비즈니스 로직을 격리해 코드를 유연하게 수정하고, 코드 재사용 용이, 코드를 읽기 쉽게 한다.
domain 모듈은 앱의 중심부로서 이 계층에 포함된 비즈니스 로직은 앱을 구성하고 있는 것 중 가장 중요한 부분이다. 따라서 어떠한 계층에도 의존하지 않는다.
domain 모듈은 다음과 같은 코드를 포함한다.
- Entity : 특정 영역을 표현하는 객체
- UseCae : Entity와 함께 비즈니스 로직 수행
- Repository 인터페이스 : DB, 서버와 같은 데이터 소스에 접근
domain 모듈은 비즈니스 로직들을 한 계층에서 관리하는데 초점을 맞춰 코드를 깨끗하게 관리한다.
UI 또는 프레임워크 코드는 빈번히 변경될 수 있고 비즈니스 로직과 관련 없는 내용이므로 domain 모듈 분리는 매우 중요하다.
data 모듈
data 모듈은 데이터 소스(DB, 서버 등)와 상호작용을 담당하는 코드를 포함한다. data 모듈은 domain 모듈에 의존성을 가지고 있다. 또한, mapper 클래스를 통해 Data 모듈을 Domain 모듈로 변환해주는 역할도 한다.
데이터 소스는 시간이 지남에 따라 변경될 수 있다. 이러한 변경은 오로지 데이터를 처리하는데 관련된 로직이므로 데이터를 필요로 하는 코드에는 영향을 미치지 않는다.
data 모듈은 다음과 같은 책임을 갖는다.
- 데이터 입출력 코드를 하나의 계층에서 관리
- 데이터 소스들과 데이터를 소비하는 다른 계층관의 경계를 둠
data 모듈에서는 domain 모듈에서 정의한 Repository 인터페이스를 구현한다.
presentation 모듈
presentation 모듈은 domain 모듈과 data 모듈에 의존한다. presentation 계층은 UI와 관련된 코드를 캡슐화한다. Activity, Fragment, View, Presenter 및 ViewModel 모든 UI와 관련된 컴포넌트 또는 안드로이드 프레임워크와 관련된 코드들을 이 계층에서 다룬다.
UI는 비즈니스 로직에 비해 상대적으로 변경할 일이 많다. 또한, UI와 관련된 유닛테스트는 어렵기 때문에 UI와 관련된 내용은 다른 코드에서 의존성이 없도록 최대한 독립적으로 만들어야 한다. 따라서 UI 코드를 한 곳에 관리함으로써 비즈니스 로직을 보호하고, 테스트도 쉽게 만든다.
참고
