[Android] Clean Architecture in Android

Clean Architecture

본격적인 디자인 패턴 공부에 앞서, clean Architecture에 대해 알아보겠습니다

Clean Architecture에 가장 중요한 부분은 UI와 Data를 분리함에 있습니다

관심사를 계층별로 분리

 

관심사란 단어가 잘 와닿지 않는데 정의를 알면 이해가 쉽습니다

관심사는 어떤 상태나 데이터에 영향을 미치는 정보의 집합을 뜻합니다

 

Clean Architecture Layer

각 계층별로 반드시 코드의 종속성이 외부로부터 내부로 의존
(Entities <- Usecases <- Presenter <- UI)
즉, 내부 계층의 코드는 외부 계층을 알면 안됩니다

이렇게 계층간의 의존도가 단방향이라 코드 재사용성이 용이하고, 유닛 테스트가 쉽습니다

1. Entities

데이터의 구조나 메서드를 포함하는 객체

 

외부 변경에 따라 가장 영향을 받지 않는 layer입니다 (화면 이동, 보안관련 변경)

ex) POJO같은 데이터 클래스

2. Usecases

비즈니스 규칙, 데이터 흐름 관리

 

Entity로 부터 데이터 흐름을 관리, 사용자의 행동들을 나열
ex) Model, Repository, Executor

3. Presenter (Interface Adapters)

Usecases나 Entity로 부터 얻은 데이터를 가공

 

UI에 데이터를 표시하기 위해 형식을 변경하거나 UI로부터 얻은 데이터를 가공하여 전달
비즈니스 로직과 framework 연결하는 역할

 

ex) ViewModel, View, Presenter, Controller

 

4. Framework

UI와 관련된 Component, DataSource, Retrofit 같이 네트워크 관련 framework

 

ex) Activity, Fragment, ContentProvider, Database

---

Clean Architecture in Android Layer

3개의 계층으로 분류

 

 

Presentation Layer

- 화면에 Data를 표시해주는 계층 사용자 상호작용 또는 외부 입력으로 인해 데이터가 변동 시 변경사항을 반영하도록 UI가 업데이트

- UI, Presenter가 여기에 해당하고, Domain계층에 의존도를 가집니다

 

ex) View, Presenter, Fragment, Activity, ViewModel

 

Domain Layer

- 비즈니스 로직을 담당하고 Framework와 관련 없는 순수 Java, Kotlin으로 구성
- 어떤 계층에도 의존성을 가지지 않습니다

 

ex) Usecase(사용자 행동의 최소 단위), Entity, Repositor

 

Data Layer

- DB, API와 통신하여 DataSource를 처리 및 반환
- Data Model의 Mapper 클래스

ex) Room, SharedPreference

 

---

Android 권장 Application 설계

관심사 분리에 따라 권장되는 안드로이드 설계 다이어그램은 아래와 같습니다

 

 

📌 Activity/Fragment는 ViewModel만을 참조 

📌 ViewModel : Repository라는 저장소 참조, 이 저장소로 부터 UI 구성에 필요한 데이터를 가져옴

📌 데이터를 불러와 관찰가능한 LiveData 형태로 관리

📌 Repository는 내부모델(SQLite, Room, Realm), 원격모델(서버와의 통신)을 참조

---

해당 포스팅은 계속 업데이트 할 예정이며,
안드로이드의 설계 패턴에 대해선 다음 포스팅으로 이어하겠습니다
감사합니다 🥳