[도토링] 안드로이드 권장 아키텍처 vs 클린 아키텍처
멘토링 애플리케이션 도토링의 안드로이드 아키텍처 설계 과정을 담아보겠다.
먼저, 아키텍처를 잘 짜야하는 이유가 무엇일까?
안드로이드 공식문서에는 이렇게 나와있다.
Android 앱은 크기가 커지기 때문에 앱을 확장하고 앱의 견고성을 높이며 앱을 더 쉽게 테스트할 수 있도록 아키텍처를 정의하는 것이 중요합니다.
앱 아키텍처는 앱의 부분과 그 각 부분에 필요한 기능 간의 경계를 정의합니다. 위에 언급된 요구사항을 충족하려면 몇 가지 특정 원칙을 준수하도록 앱 아키텍처를 설계해야 합니다.
앱 개발 중 기능을 수정하거나 오류가 생겼을 때 의존성 규칙이 잘 짜여있지 않고 관심사 분리가 잘 되어있지 않다면 수정할 부분이 많아질 뿐더러 찾기도 어려울 것이다.
이를 예방하기 위해 아키텍처 설계에는 관심사의 분리가 중요하다.
안드로이드 권장 아키텍처
이제 안드로이드의 권장 아키텍처를 보여주겠다.
UI 레이어는 도메인 레이어를 알 수 있으며, 도메인 레이어는 데이터 레이어를 알 수 있다.
여기서 UI 레이어는 사용자에게 보여지는 부분을 담당하고, 데이터 레이어는 데이터와 비즈니스 로직을 담당한다.
그렇다면 도메인 레이어는 무슨 역할을 하는 것일까?
도메인 레이어는 복잡한 비즈니스 로직과 자주 재사용되는 로직의 '캡슐화'를 담당한다.
만약 여러 ViewModel에서 재사용되는 로직이 있다면 클래스로 분리 후 ViewModel에서 클래스를 참조하여 사용한다.
그래서 복잡한 비즈니스로직이나 재사용성을 선호한다면 도메인 레이어를 사용할 수 있지만, 그림에 적혀있듯이 안드로이드 권장 아키텍처에서 도메인 레이어는 선택적이다.
그냥 UI 레이어, 도메인 레이어, 데이터 레이어 라고만 하면 와닿지 않아 위의 표를 참고하였다.
안드로이드 권장 아키텍처에는 레포지터리 인터페이스가 데이터 레이어에 위치하여 도메인 레이어가 데이터 레이어를 알아야한다.
클린 아키텍처
자 이제 클린 아키텍처는 무엇일까?
구글에 클린 아키텍처를 검색하면 이런 그림을 볼 수 있었을 것이다.
각 계층은 하위 계층에 의존하지만, 상위 계층에 대해서는 알지 못한다. 이러한 방식으로 시스템은 더욱 모듈화되고 유연해지며, 수정과 유지보수가 용이해진다..
클린 아키텍처는 의존성 역전 원칙을 기반으로 하고있다.
의존성 역전 원칙이 뭔가요?
의존성 역전 원칙(DIP)이란, 한 클래스가 어떤 기능을 수행하려 할 때, 다른 클래스의 서비스가 필요한 경우를 말한다.
대표적으로 A 클래스의 메소드에서 매개변수를 다른 B 클래스의 타이으로 받아 B 객체의 메서드를 사용할 경우,
A 클래스는 B 클래스와 의존한다고 말한다.
아래 그림에서 클라이언트가 상속관계로 이루어진 모듈을 사용할 때, 하위 모듈의 인스턴스를 직접 가져다쓰는 것이 아닌, 인터페이스를 통해 가져온다는 것이다.
그렇게 해야 하위 모듈의 내용에 변동이 있어도 수정이 덜 필요하게 된다.
이를 위해 클린 아키텍처에서는 도메인 레이어가 필수이다.
안드로이드 권장 아키텍처와 클린 아키텍처 의존성 방향을 한눈에 보자면
안드로이드 권장 아키텍처: UI 레이어 -> 도메인 레이어(선택) -> 데이터 레이어
클린 아키텍처: UI 레이어 -> 도메인 레이어 <- 데이터 레이어
클린 아키텍처에서는 도메인레이어가 필수이고 도메인 레이어에서 비즈니스 로직과 유스케이스를 처리해야 한다.
하지만 안드로이드 권장 아키텍처에서는 도메인 레이어가 선택이며 모든 비즈니스 로직이 도메인에 있을 필요가 없고 픽요에 따라 도메인 레이어를 추가한다.
그래서 안드로이드 권장 아키텍처에서는 레포지터리 인터페이스가 데이터에 위치했지만 클린 아키텍처에서는 도메인 레이어에 위치한다.
아래 표는 클린 아키텍처의 디렉토리 구조이다.
아키텍처 및 디렉토리 구조 회의를 한 결과 도토링은 클린 아키텍처를 따르기로 했다.
그 이유는 도토링의 확장성 때문이다.
도토링은 현재 안드로이드 애플리케이션만 개발중이지만, 추후 접근성을 위하여 iOS 및 웹으로도 확장 가능성을 열어두고 있기 때문이다.
클린 아키텍처로 개발을 진행하면 중간에 도메인 모듈 자체가 어떠한 언어로든 프레임워크나 라이브러리에 종속되지 않아 모듈화와 유연함이라는 장점이 있어 확장성이 좋을 것이라고 판단하였다.
참조
헤이딜러 안드로이드팀은 어떻게 일하나요?(3) — 프로젝트 구조
완벽하게 이해하는 DIP (의존 역전 원칙)
Clean 과 Google Recommended Architecture 이야기
앱 아키텍처 가이드 - Android developers