[Android] Clean Architecture, AAC

Arkiee·2022년 11월 8일

AAC Android Jetpack android android-architecture-components clean architecture 안드로이드

Android

목록 보기

2/3

Clean Architecture란

Clean Architecture는 계층을 크게 나눠서 관심사를 분리하고 각 분리된 클래스가 한 가지 역할만 할 수 있도록 구현하는 방식입니다.

또한, 계층 구조에서 외부에서 내부로 의존성을 가지고 있기 때문에 내부로 갈수록 의존성은 낮아지게 됩니다.(의존성 규칙) 즉, 어떤 동작을 할 때 자기보다 내부에 있는 계층이 변화하면 동작을 행하는 계층에도 영향이 있을 수 있지만(의존성이 있음), 자신의 외부에 있는 계층이 변화하는 것 때문에 동작을 행하는 계층에 영향이 있어서는 안 됩니다.(의존성이 없음)

그렇기 때문에 계층 내부로 들어갈수록 의존하는 성격이 낮아지게 됩니다.

예를들어, 위 이미지에서 가장 바깥의 DB와 가장 내부의 Entitiy를 봅시다. DB기준으로 Entity가 변화하게 되면 DB 자체에서 저장할 데이터 타입이 변경될 가능성이 있는 등 내부의 변화로 인해 동작을 하는 계층에 영향이 갈 수 있습니다. 하지만, Entity는 실제 사용할 데이터 클래스이므로 DB가 변경되더라도 Entity에는 아무런 영향이 없어야 합니다.

반대로, Entity는 가장 내부에 있으므로 다른 어떤 계층의 변화에도 영향을 받지 않으며, 오로지 자신의 변화만이 다른 계층에 영향을 끼칠 수 있습니다. 이것이 DB(바깥)가 의존성이 높고, Entity(내부)가 의존성이 낮다는 의미입니다.

이렇게 계층을 분리하고, 의존성을 내부로 향하게 하는 식으로 구현을 해서 다양한 이점을 갖도록 설계를 하는 것이 '클린 아키텍처' 입니다.

왜 Clean Architecture를 사용할까?

클린 아키텍쳐 창시자인 Robert C. Martin가 운영하는 The Clean Code Blog에 의하면, 클린 아키텍쳐가 시스템에 주는 이점은 아래와 같습니다.

1. Clean Architecture는 프레임워크에 독립적입니다.

일부 기능이 포함된 라이브러리에 의존하지 않습니다.
이를 통해 프레임워크의 제약에 시스템을 맞추는 것이 아니라, 시스템의 도구로써 프레임워크를 활용할 수 있게 합니다.

2. Clean Architecture는 테스트를 용이하게 합니다.

The business rules(Entity)를 테스트하는데 외부 요소가 필요하지 않습니다.

3. Clean Architecture는 UI에 독립적입니다.

다른 시스템 변경 없이, UI를 쉽게 변경할 수 있습니다.
예를들어, 웹 UI에서 Console UI로 변경할때, Entity 변경없이 그대로 사용가능

4. Clean Architecture는 DB와 독립적입니다.

The business rules(Entity)가 DB에 바인딩 되지 않으므로, DB의 종류를 쉽게 변경할 수 있습니다.
예를들어, Oracle에서 SQL Server, Mongo, BigTable 등으로 쉽게 변경가능

5. Clean Architecture는 외부와 독립적입니다.

The business rules(Entity)는 외부에 대해 알 필요가 없고 알지 못합니다.
이 덕분에 1~4의 이점을 가져올 수 있는 것입니다.

Clean Architecture의 Layer

안드로이드 클린 아키텍쳐에서 사용되는 3가지 계층은 Presentation, Domain, Data 계층입니다. 아래 그림은 위의 그림을 90도 회전한 모습입니다.

Presentation Layer(UI Layer)

위 그림의 Presenter는 Presenter뿐 아니라 ViewModel도 포함하므로 Controllers로 칭하겠습니다.

UI(Activities & Fragments), Controllers, DI, Module를 포함합니다.
Controllers은 1개 이상의 Use cases를 실행합니다.
UI은 각각의 Controllers에 의해 조정됩니다.
Presentation Layer는 Domain Layer을 대상으로 의존성을 가집니다.
View는 가능한 단순해야되며 비즈니스 로직을 넣지 말아야합니다.

Presentation Layer ---> Domain Layer

Domain Layer

Entity, Use case, Repository Interface를 포함합니다.
애플리케이션의 모든 UseCase를 가지고 있습니다.
UseCase의 목적은 ViewModel과 Repository 사이의 중재자 역할입니다.
Use case는 data와 1개 이상의 Repository Interface를 결합합니다.
Domain Layer는 가장 안쪽 층입니다. 의존성 법칙에 의해 다른 층을 대상으로 의존성을 가지지 않습니다. 다른 레이어가 Domain Layer를 대상으로 의존성을 가질 뿐입니다.
가장 중요한 레이어로 다른 레이어와 달리 빈번히 바뀌면 안됩니다.
Android Platform(프레임워크)에 의존성을 가지지 않고 오직 언어(Kotlin Module)에 의존성을 갖습니다.

Data(DataSource) Layer

Domain 층에 의존성을 가지고 있으며 Data들을 control(CRUD)하는 계층입니다.

Domain Layer에서 사용할 수 있는 모든 Repository를 갖고 있습니다.
Cache, Room DB, Dao, Model 서버 API(Retrofit2)을 포함합니다.
Repository 구현체, 1개 이상의 Data Source를 포함합니다.

Repository는 다른 Data Source들을 결합/조정합니다.

Local Data Source와 Remote Data Source의 결합

dataSource와 dataSourceImpl
Data Layer의 Data Source도, 위에서 봤던 의존성 역전 법칙의 적용으로, 추상화되어 interface와 Implementation으로 구성됩니다.
즉, Repository-->Data Source의 의존에 대한 회피입니다.

AAC(Android Architecture Component)

AAC가 나온 이유

Android Architecture Components(이하 AAC)는 'Google I/O 2017'에서 처음 발표된 라이브러리 모음입니다.

구글에서 AAC를 제공한 이유는 Android를 구성하는 Component(Activity, Service, BroadcastReceiver, ContentProvider)가 서로 다른 생명주기(LifeCycle)을 가지고 있으며 이들의 생명주기를 잘 연결할 뿐만 아니라 컴포넌트들을 서로 잘 연결해서 더욱 손쉽게 앱을 개발해나가도록 가이드하기 위함입니다.

당시는 라이브러리 묶음으로 AAC를 칭했지만, Android Jetpack이 2018년 나오면서 AAC가 jetpack의 구성요소로 변경됐습니다.

공식문서에 AAC로 정의된 라이브러리들을 확인해보면 다음과 같습니다.