안드로이드 클린 아키텍처

최근 회사에서 프로젝트를 진행하면서 '클린 아키텍쳐'라는 것을 처음 들었다.

물론 클린 아키텍쳐라는 용어에서 오는 느낌에서부터, 코드를 깔끔하고, 객체 지향적으로 짜기 위한 아키텍쳐일 것이라는 느낌이 오기는 했다. 그런 의미에서 안드로이드 클린 아키텍쳐에 대해 알아보자.

 

클린 아키텍처란?

2012년 Uncle Bob은 Clean Architecture라는 새로운 소프트웨어 아키텍처 패턴을 발표했습니다. 그는 이 패턴을 활용한다면 SW 개발의 체계적인 구조와 계층들을 분할함에 따라 이전보다 효율적으로 프로그램을 구현가능할 것이라고 말했습니다.

출처: https://juyeop.tistory.com/25 [글 쓰는 개발자의 꿈]

Uncle Bob이라는 사람이 발표한 것으로, 엔터프라이즈에서 논의되고 있던 내용을 집약시킨 개념이라고 한다. 아키텍처 패턴의 구조는 아래와 같다.

 

출처 : 도서출판 인사이트

각 계층에 대한 의존성은 항상 경계 안쪽을 향하고, 내부의 원은 바깥 원을 알아서도, 접근해서도 안 된다는 것이 규칙이다.

 

각각에 대한 개념을 살펴보면 다음과 같다.

 

Presentation 레이어

Presentation 레이어는 UI와 관련된 로직을 수행하며 Android와 직접적으로 관련된 일들이 많아 의존성이 가장 높다. 또한 이는 아래의 레이어들을 자유롭게 참조 가능하다

 

Data 레이어

Data 레이어는 실질적으로 상세 로직을 구현하는 레이어이다. 이는 Domain 레이어를 참조 가능하며 Domain 레이어에서 정의한 Repository 인터페이스를 참조하여 Repository를 실질적으로 구현하는 역할이다. 또한 Data 레이어는 DataSource에게 의존성이 생겨 Android 안드로이드와 관련된 Network 관련 서버 통신을 수행하는 중요한 역할을 한다.

 

Domain 레이어

Domain 레이어는 위의 Presentation, Data 레이어 심지어 Android 안드로이드와 어떠한 의존성도 이루지 않는다. 주로 하는 역할은 사용자의 행동 즉 Usecase를 참고하여 Data 레이어에서 Repository를 실직적으로 구현할 수 있도록 Repository 인터페이스를 구성한다. 또한 Domain 레이어는 순수한 Java 또는 Kotlin 모듈로 구성되며 비즈니스 로직을 구현하는 역할을 한다.

 

Entity 레이어

Entitiy 레이어는 위의 Domain 레이어에서 파생된 개념이다. Domain 레이어와 같이 어떠한 곳에 대해서도 의존성을 이루지 않으며 순수한 Java 또는 Kotlin 모듈로 구성된다. 또한 다른 플랫폼에서 같은 서비스를 구현한다면 Entity 레이어는 플랫폼에 관계없이 동일한 형태로 구성해야 한다. 보통 Clean Architecture 패턴을 구현하는 개발자들은 Entity 레이어를 포함한 4가지의 계층들을 그대로 사용하지 않으며 이를 재구성하여 Presentation, Data, Domain 총 3가지의 계층으로만 구현한다.

 

아래의 경우에는 클린 아키텍처를 안드로이드에 적용했을 때의 모습이다.

 

 

Clean Architecture Guide (with tested examples): Data Flow != Dependency Rule

 

의존성은 바깥에서 안으로만 향하고 있다.

MVVM에서 Model은 Domain과 Data 계층에 해당한다.

Domain Layer는 Usecase를 가지고 있고, Usecase는 1개 이상의 *Repository를 받아서 비즈니스 로직을 처리한다. 하나의 유저의 행동에 대한 비즈니스 로직을 갖는다. (1개의 유저 행동에 따른 1개의 로직을 반환한다)

DataSource는 데이터가 어디서 오는지를 관장한다.

 

*Repository : Repository는 디자인 패턴 중 하나로, 데이터가 있는 어떤 저장소이건 데이터를 사용하는 로직에서 분리시키고자 하는 것이다. 도메인 레이어와 데이터 레이어를 중재하는 매핑 레이어로 도메인 객체에 접근하기 위한 콜렉션과 같은 인터페이스를 사용한다.