[Android] 클린 아키텍처(Clean Architecture)

 

앱 구성요소는 개별적이고 비순차적으로 실행될 수 있으며, 운영체제나 사용자가 언제든지 앱 구성요소를 제거할 수 있습니다. 이러한 이벤트는 직접 제어할 수 없기 때문에 앱 구성요소에 애플리케이션 데이터나 상태를 저장해서는 안 되며 앱 구성요소가 서로 종속되면 안됩니다.

즉, Android 앱은 크기가 커지기 때문에 앱을 확장하고 앱의 견고성을 높이며 앱을 더 쉽게 테스트할 수 있도록 아키텍처를 정의하는 것이 중요합니다.

 

위의 내용은 안드로이드 공식 문서 중 앱 아키텍처 가이드에 기재되어있는 내용이다.

이러한 내용을 읽어보면 아키텍처 공부를 해야하는 이유가 점점 더 명확해진달까 ..~

 

---

 

관심사 분리

보통 처음 코딩을 시작하면 Activity와 Fragment에 모든 코드를 작성하는데, 이런 UI 기반의 클래스는 UI 및 운영체제 상호작용을 처리하는 로직만 포함해아 한다. 이러한 클래스를 최대한 가볍게 유지하여 구성요소 수명 주기와 관련된 많은 문제를 피하고 그러한 클래스의 테스트 가능성을 개선할 수 있다.

즉, 만족스러운 사용자 환경과 더욱 수월한 앱 관리 환경을 제공하려면 이러한 클래스에 대한 의존성을 최소화해야한다.

 

 

클린 아키텍처의 구조 및 특성

 

 

클린 아키텍처의 구조는 다음과 같이 4가지 계층으로 되어있다.

계층을 분리하는 이유는 관심사를 분리시키기 위해서이며 이런 아키텍처가 동작하기 위해서는 의존성 규칙을 지켜야한다. 여기서 의존성 규칙은 모든 소스 의존성은 반드시 외부에서 내부로, 고수준 정책을 향해야한다는 것이다. 이를 통해 비즈니스 로직(고수준 정책)은 세부 사항들(저수준 정책)의 변경에 영향을 받지 않도록 할 수 있다.

 

이로부터 오는 이점

- 코드 테스트 커버리지 증대

- 쉽게 패키지 구조 탐색 가능

- 집중화된 클래스에 따른 프로젝트 유지 관리 증대

- 새 기능을 빠르게 적용 가능

- 이후의 개발에서의 안정적인 구현

- 명확한 규율로 전반적으로 따라야 할 베스트 프랙티스

 

 

- 각 계층의 역할

1. Entities : 가장 일반적인 비즈니스 규칙을 캡슐화하고 DTO(Data Transfer Object)도 포함하는 전사적 비즈니스 규칙이다. 외부가 변경되면 이러한 규칙이 변경 될 가능성이 가장 적다

2. Use cases: Interface라고도 하며 소프트웨어의 애플리케이션 별 비즈니스 규칙을 나타냄. 이 계청은 데이터베이스, 공통 프레임 워크 및 UI에 대한 변경으로부터 격리 됨.

3. Interface Adapter(Presenters): 인터페이스 어댑터는 데이터를 Entitiy 및 UseCase의 편리한 형식에서 데이터 베이스 및 웹에 적용할 수 있는 형식으로 변환한다. 이 계층에는 MVP의 Presenter, MVVM의 ViewModel 및 게이트웨이 (= Repositories)가 포함됨. 즉, 순수한 비즈니스 로직만을 담당하는 역할을 하게 됨.

4. Frameworks & Drivers (Web, DB): 프레임워크와 드라이버는 웹 프레임 워크, 데이터베이스, UI, HTTP 클라이언트 드응로 구성된 가장 바깥 쪽 계층이다. 

 

 

안드로이드에서의 클린 아키텍처 구조

 

안드로이드용 클린아키텍처 구조는 Entity 레이어를 따로 두지않고 일반적으로 Presentation, Domain, Data로 나눠져있다.

 

권장 앱 아키텍처

각 애플리케이션에는 레이어가 두 개 이상 있어야 한다.

- 화면에 애플리케이션 데이터를 표시하는 UI 레이어

- 앱의 비즈니스 로직을 포함하고 애플리케이션 데이터를 노출하는 데이터 레이어

+) UI와 데이터 레이어 간의 상호작용을 간소화하고 재사용하기 위한 도메인 레이어라는 레이어 추가 가능

다이어그램의 화살표는 클래스 간의 종속 항목 나타냄. 도메인 레이어는 데이터 레이어 클래스에 의존한다.

 

 

- UI 레이어

UI 레이어의 역할은 화면에 애플리케이션 데이터를 표시하는 것이다. 사용자 상호작용 또는 외부 입력으로 인해 데이터가 변할 때마다 변경사항을 반영하도록 UI가 업데이트되어야 한다.

+) UI(Activity, Fragment), Presenter 및 ViewModel을 포함. 즉, 화면과 입력에 대한 처리 등 UI와 직접적으로 관련된 부분을 담당. 또한, Presentation 레이어는 Domain과 Data 레이어를 포함하고 있다는 특징이 있다.

UI 레이어의 구성

1. 화면에 데이터를 렌더링하는 UI 요소. 이러한 요소는 뷰 또는 Jetpack Compose 함수를 사용하여 빌드 가능

2. 데이터를 보유하고 이를 UI에 노출하며 로직을 처리하는 상태 홀더 (ex) ViewModel 클래스)

 

- 도메인 레이어

도메인 레이어는 UI레이어와 데이터 레이어 사이에 있는 선택적 레이어이다. 도메인 레이어는 복잡한 비즈니스 로직 또는 여러 ViewModel에서 재사용되는 간단한 비즈니스 로직의 캡슐화 담당한다. 복잡성을 처리하거나 재사용성을 선호하는 등 필요한 경우에만 도메인 레이어를 사용한다.

+) 애플리케이션의 비즈니스 로직을 포함하고 비즈니스 로직에서 필요한 Model과 UseCase 포함함. UseCases는 보통 한 개의 행동을 담당하고 UseCase의 이름만 보고 이게 무슨 기능을 가졌을지 짐작하고 구분할 수 있어야한다. 추가로 Domain 레이어는 Presentation, Data 레이어와 어떤 의존성도 맺지 않고 독립적이다.

 

- 데이터 레이어 (Repositories, Data sources)

앱의 데이터 레이어에는 비즈니스 로직이 포함되어 있다. 비즈니스 로직은 앱에 가치를 부여하는 요소로, 앱의 데이터 생성, 저장, 변경 방식을 결정하는 규칙으로 구성된다.

데이터 레이어는 0개부터 여러 개의 데이터 소스를 각각 포함할 수 있는 저장소로 구성. 앱에서 처리하는 다양한 유형의 데이터마다 저장소 클래스를 만들어야한다.

저장소 클래스에서 담당하는 작업으로는 앱의 나머지 부분에 데이터 노출, 데이터 변경사항을 한 곳에 집중, 여러 데이터 소스 간의 충돌 해결, 앱의 나머지 부분에서 데이터 소스 추상화, 비즈니스 로직 포함

각 데이터 소스 클래스는 하나의 데이터 소스만 사용해야한다. 데이터 소스 클래스는 데이터 작업을 위해 애플리케이션과 시스템 간의 가교 역할을 한다. 

+) Repository 구현체, Cashe, Room DB, Dao, Model 서버 API (Retrofit2)을 포함하고 있으며 로털 또는 서버 API와 통신하여 데이터를 CRUD하는 역할을 함. 또한, Mapper 클래스도 포함하고 있는데 DB로 부터 받아온 데이터모델과 UI에 맞는 데이터 모델간의 변환을 해주는 역할을 함. 추가로 Domain레이어를 포함함.

* Repository: 도메인과 데이터 레이어들 사이를 중재해주는 객체

 

 

 

 

+) 예제 코드는 좀 더 공부하고 업로드 하겠음!