[Android] Clean Architecture 모듈화 해보기 - 1

클린 아키텍처에 대해 공부하는데, 모듈별로 분류되어 있는 자료는 많이 접해보지 않아 직접 한 번 해보려고 합니다.

클린 아키텍처에 대해 간단히 소개하자면,

프로젝트를 진행하면서 규모가 점점 커질수록 매우 복잡해집니다. 또한, 그만큼 의존성과 유지보수, 빌드 속도도 저하될 수 있는 환경이 되기 쉽죠.

이러한 프로젝트에서 각 할 일들(관심사)에 따라 패키지 구조를 나눈 것이 클린 아키텍처라고 할 수 있습니다.

 

그럼, 클린 아키텍처를 도입하면 무엇이 좋아질까요?

 

1. 각 관심사에 따라 코드를 분리하였기 때문에 유지보수가 용이합니다.

2. 1번으로 인해 테스트 코드 작성이 용이합니다.

3. 새로운 기능을 추가하기가 매우 간단합니다.

4. 의존성을 더욱 약화시킬 수 있다.

 

물론 장점만 있는 것은 아닙니다. 제가 생각할 때 단점은 다음과 같습니다.

 

1. 해당 프로젝트를 이해하기 위한 러닝커브가 상승합니다.

2. 1번과 같은 이유로 오히려 너무 많은 모듈 때문에 잘못 관리하다간 더욱 복잡해집니다.

3. 너무 많은 의존성을 생각하다 보니 오히려 일의 효율을 떨어뜨릴 수 있습니다.

 

 물론 위와 같은 단점들은 실력 좋으신 분들은 설계를 잘하시니 상관없지만, 저 같은 초보분들은 어려운 부분이 될 수 있다고 생각합니다... 어쨌든 계속하자면,

 

 보통 안드로이드에서 클린 아키텍처는 다음과 같이 패키지를 나눕니다

- presentation
- domain
- data

또한 의존성은 다음과 같이 구성됩니다.

 

presentation -> domain <- data

 presentation: 보통 UI와 관련된 부분을 처리합니다. Activity, Fragment, ViewModel 등을 갖고 있습니다.

 

 domain: 프로젝트의 핵심 비즈니스 로직을 포함하고 있습니다. 여기엔 UseCase와 Repository(interface), Model 등을 갖고 잇습니다. 또한, 해당 layer는 java 및 kotlin, 간단한 Coroutine 코드로만 구성할 수 있으며, 그 외의 안드로이드 코드는 포함할 수 없기에 의존성을 갖지 않습니다.

 * 해당 UseCase만 봐도 이 앱이 어떤 기능을 하는 앱인지 알아보기 쉽게 파일 이름을 짓는 것이 좋다고 합니다.

 

 data: 로컬 DB나 서버 통신하여 가져온 Data를 가져오고, 그것을 처리하는 계층입니다. domain의 Repository(interface)를 구현한 Repository(Impl)와 model, mapper 등을 갖고 있습니다.

 

* 의존성 역전 (Dependency Inversion)

 domain의 repository가 interface를 구현하고, data의 repository가 실제 구현(impl)하여 상위 layer가 하위 layer의 구현을 독립시킬 수 있습니다.

 

 

그러면 클린 아키텍처를 도입하여 패키지별로 나누면 되지, 굳이 module로 나눠야 하는 이유가 있는지 의문이 생길 수 있습니다.

 

사실 패키지만으로 나눠도 상관없습니다. 이것은 단지 '약속' 이니까요. 그러나 모듈별로 분리하면 더욱 큰 이점을 볼 수 있습니다.

 

1. 위 4번에서 말한 의존성 약화가 더욱 정확하게 할 수 있습니다. 패키지별로 진행하다 보면 그냥 마구잡이로 import 하는 경우가 많은데(특히 자동 import), 모듈별로 분리하면 build.gradle의 dependency에 의존성을 추가해야 하기 때문에 더욱 알기 쉽습니다.

 

2. 위 2번에서 말한 것처럼 테스트가 더욱 쉽습니다. 모듈별로 분리하면 각 테스트할 수 있는 파일들이 각 모듈별로 생기기 때문에 관심사에 따른 테스트 코드도 나눌 수 있고, 의존성이 약하기 때문에 테스트하기 좋은 환경이 만들어집니다.

 

이렇게 클린 아키텍처에 간단히 알아봤습니다. 다음 장에선 이미 완성된 클린 아키텍처 프로젝트를 각 기능을 모듈별로 나누어서 진행하겠습니다.

 

 

감사합니다.