[Android] 앱 아키텍처 설계

이 글은 원격 진료 프로젝트의 안드로이드 아키텍처 설계를 정리한 내용입니다.

 

아키텍처 설계의 필요성

그동안 여러 프로젝트를 개발하며 기획이 중간중간 변경되는 경우가 빈번했고 그때마다 코드 대공사를 거쳤습니다. 배포 후 유지 보수는 산 넘어 산이였습니다. 기획이 변경될 때 의존성 규칙 없이 꼬여 있는 코드는 수정할 부분이 매우 많았고 점점 복잡해졌습니다. 이로 인해 좋은 아키텍처 설계에 대한 고민을 하기 시작했습니다.

그동안의 경험을 바탕으로 어떤 조건이 필요한지 정리해 보았습니다.

1. 기능 변경, 확장에 유연할 것

2. 테스트가 용이할 것

3. 코드 간 의존성이 적을 것

4. 구조를 이해하기 쉬울 것

 

 

앱 아키텍처 설계

Robert C. Martin의 클린 아키텍처를 참고해 구조를 설계했고 디자인 패턴은 MVVM을 적용했습니다. 

프로젝트 구조를 Presentation Layer, Domain Layer, Data Layer 3개의 레이어로 나눴습니다.

 

아키텍처 흐름은 아래와 같이 설계하였습니다. 중요한 점은 비즈니스 로직을 독립적으로 분리했다는 것입니다.

아래 이미지와 같이 계층을 나눠 관심사를 분리하였습니다. 의존성 규칙은 원 외부에서 내부로, 저 수준에서 고수준 정책으로 향합니다.

Presentation Layer

UI를 처리하는 데 중점을 둔 계층입니다. View, ViewModel을 포함합니다. ViewModel은 View와 도메인 계층의 UseCase 사이의 커넥터 역할을 담당합니다. Presentation Layer는 Domain Layer를 대상으로 의존성을 가집니다.

 

Domain layer

비즈니스 로직과 관련된 가장 핵심 계층입니다. UseCase, Model, Repository Interface를 포함합니다. UseCase는 UI와 상호작용하여 Repository에서 데이터를 꺼내옵니다. UseCase는 일반적으로 한 개의 행동을 담당하며, 이름만 보고 무슨 기능을 가졌을지 짐작하고 구분할 수 있어야 합니다. 

 

* Domain Layer는 어떠한 의존성도 갖지 않고 독립적입니다. 의존성 역전 원칙((Dependency Inversion Principle)을 이용해 모든 의존성이 도메인 코드를 향하게 해야 합니다. Domain Layer에서 Repository를 인터페이스로 만들고 Data Layer에서 구현합니다.

 

Data layer

데이터 관리에 중점을 둔 계층입니다. Repository Implementation, Local & Remote Data source를 포함합니다. 로컬 또는 서버 API와 통신하여 데이터를 CRUD 하는 역할을 합니다. Mapper 클래스는 DB로부터 받아온 데이터 모델과 UI에 맞는 데이터 모델 간의 변환을 해주는 역할을 합니다. Data Layer는 Domain Layer를 대상으로 의존성을 가집니다.

 

클린 아키텍처 데모 프로젝트

클린 아키텍처 + MVVM 디자인 패턴을 구현한 데모용 프로젝트입니다.

 

GitHub

https://github.com/shruddms/CleanArchitecture

 

클린 아키텍처 구현 후기

실제로 앱에 적용해 보니 기능 변경 및 확장 부분에서 확실히 용이해졌습니다. 프로젝트에서 앱 디자인이 크게 변경되었었는데 비즈니스 로직을 잘 분리해둔 덕분에 Presentation Layer 단만 수정해 변경 사항을 빠르게 적용할 수 있었습니다. 전체적으로도 기능 변경. 확장 시에 코드 수정 양이 현저히 감소했습니다. 

 

프로젝트마다 상황과 기간이 다 다르기에 좋은 아키텍처에 딱 정해진 정답은 없는 것 같습니다. 기간이 짧은 프로젝트에는 굳이 복잡한 클린 아키텍처가 필요할까?라는 생각도 들었습니다. 아키텍처 설계를 할 때 주어진 상황을 잘 고려하는 것이 중요한 포인트인 것 같습니다. 

 

결론)

클린 아키텍처가 정말 클린 한지에 대해서는 논란이 많지만 개인적으로는 단점보다는 장점이 많은 아키텍처라고 느꼈습니다.