nowinandroid 의 프로젝트 구성에 대해 분석을 시작해보자.
처음 안드로이드 클린 아키텍처에 대해 알게 되었을 때는 분명, 크게 3가지 모듈로 분리되었다고 했다.
- presentation
- modain
- data
헌데 nowinandroid 는 그렇게 단순하지 않았다. 심지어 동일한 이름의 모듈은 첫눈에 보이지도 않는다.
이 3가지 대단위 모듈을 어떤식으로 분산시킨것일까?
모듈들을 일단 분류해보기로 했다. presentation, domain, data 에 해당하는 모듈들은 무엇일까?
- PRESENTATION
- feature 내부의 모든 모듈
- core:ui
- core:designsystem
- DOMAIN
- core:domain
- DATA
- core:data
- core:network
- core:database
- core:model
이 정도로 분류해볼 수 있겠다. 그 외에 ( app, core:common, core:analytics )등은 저 3가지에 포함된다기 보다 공통 유틸이나 분석 로직을 모듈화 해둔것으로 보인다.
계층형 아키텍처와 모듈화 전략을 결합한 구조이다 보니 상당히 복잡해 보이지만, 이렇게 분류해놓고 보니, 큰 틀의 클린 아키텍처로서 이해가 가능하다.
그렇다면 왜 이렇게 세분화하였는가? 실제 대규모 프로젝트에서는 Presentation을 기능별로 쪼개고, Data를 출처별로 쪼개서 관리하는 것이 더 효율적이기 때문에 이렇게 하지 않을까 예상해본다.
하지만 진짜 정말로 낯설고 이해하기 어려웠던 것은 따로 있다.
이전 포스팅에서 언급했던 바로 'build-logic' 모듈이다.
처음엔 단순히 무수히 많은 모듈에서 gradle 을 중복으로 호출하는 것을 방지하고, 버전 충돌을 방지하기 위해 한곳에서 관리하는 정도로 이해 했었다.
좀 더 알아보니, 단순히 그렇다기 보다는 여러가지 이유가 있었다.
-
모듈마다 반복적으로 작성되는 build.gradle.kts 파일 관리의 용이성
- 만약 minSdk 가 변경된다면 그 많은 모듈의 minSdk 를 수정해야 한다면....끔찍하다.
-
모듈이 가져가야할 설정을 하나의 플러그인에 통합하고, 관련 플러그인만 가져가면 된다.
- library, feature, room 등등 각 역할별 플러그인을 단한줄만 적으면, 수십개의 라이브러리들 설정이 한번에 가능해진다.
-
libs.versions.toml 과의 관계성
- 클린 아키텍처 이전부터 사용하긴 했지만, 이제 이 문서에서 각 라이브러리들 버전관리를 한번에 할 수 있게 된다. 내가 처음에 단순히 한곳에서 모든것을 관리한다에 해당하는 부분이라 할 수 있다.
build-logic 에 대해 물어보자 ai 는 '각 모듈이 스스로 어떻게 빌드될지 고민하지 않게 만드는 중앙 통제실' 이라고 한줄로 표현한다.
모듈이 많아질수록 이 구조가 없으면 유지보수가 매워 힘들어지기 때문에 이 방식을 강력하게 권장하는 것 같다.
build-logic 에 대해 좀 더 이해하고 한걸음 다가가게 되었다.
다음엔 직접 프로젝트를 생성하고 학습한 내용대로 구성해 보도록 하자.
이론 분석은 개발을 진행하면서 같이 하도록 하고, 이제는 실제 개발을 진행해보도록 하자.
덧, 가끔 느끼지만 구글은 자신들의 방식을 강하게 강제한다고 느낀다. 물론 이런 방식이 각각 장단점이 있겠지만, 따라가기 벅찬 나같은 개발자에게는 '이렇게만 따라로면 됩니다.' 라는 강력한 네비게이션이 되겠지만, 언젠가는 나도 이런 강제적 방식을 벗어나 나만의 방식을 찾고, 좀 더 발전된 형태의 개발을 할 수 있게 되지 않을까?
