들어가기 전에
프로젝트를 생성하기 전에 Multi-Module-Architecture 을 도입하기 위해 영상 하나를 시청했다.
[Youtebe] Don't Do These Fatal Mistakes With a Multi-Module Architecture
영상의 내용을 요약하자면
- 장점
- 빌드 시간 감소
-> 병렬적으로 빌드를 실행하기 때문에 전체적인 빌드 타임이 감소한다.
-> 변경점이 있는 모듈에 한해서만 Rebuild 하기 때문에 하나의 변경점 때문에 모두 Rebuild 하는 Single-Module 에 비해 빌드 타임이 감소한다.- 팀 별로 간섭없이 작업할 수 있음
- 관심사를 확실하게 분리할 수 있음 (위의 장점이랑 이어짐, 서로 간섭 안함)
- 재사용성
- 많이 하는 실수
- 모듈화를 너무 일찍 혹은 빠르게 한다
-> 프로젝트를 시작하면서 M-M-A 를 적용시키느라 너무 많은 시간을 낭비하게 된다
-> 프로젝트의 규모가 작다거나 Multi-Module 의 장점이 굳이 필요하지 않은 경우이거나 하는 경우에도 무조건 적용시키고 시작하느라 오히려 자원이 낭비된다
-> 필요가 생기면 그 때 마이그레이션을 진행- 레이어 기반 모듈화
-> Feature 별로 모듈화를 진행하지 않고 Clean Architecture Layer 별로 모듈화를 진행하는 경우
-> 예를 들어 Data Module + Domain Module + Presentation Module 을 말한다
-> 이렇게 하게 되면 위의 장점들이 사라진다
-> 팀 별로 작업공간이 분리되지도 않고, 변경점이 있는 모듈만 Rebuild 되지도 않으며 Reusable 하지도 않다
-> 결론은 Feature 별로 모듈화를 하되 Clean Architecture Layer 도 적용한다
(출처 : https://www.youtube.com/watch?v=p7-AffMucBw&t=540s)
프로젝트 생성
이론적인 부분은 대략 느낌으로만 이해를 했다. (사실 모르는 것)
실제로 프로젝트 내에 어떻게 적용시켜야 하는지 고민을 계속 하다가 "Best Practice 를 찾아서 내 것으로 만들어보자" 라고 생각하며 찾아봤는데 더 복잡해지는 기분이 들었다. 그대로 따라하기엔 너무 근본적인 이유를 몰랐다. 어찌하여 저런식으로 모듈을 나눈 것인지? 또한, 내가 적용하려는 부분과 안맞기도 했고...
따라서, 일단 프로젝트를 생성하고 모듈을 한 번 생성해봤다.
[File - New - New Module...] 을 선택하고, 각각 [Phone & Tablet], [Android Library], [Kotlin Library] 모듈을 생성해보았다.
Phone & Tablet
우리가 평소에 늘 생성하던 그 모듈이다. MainActivity 가 생성되며 Android app 으로써 run 시킬 수 있는 모듈이다. 해당 모듈은 안드로이드 스튜디오에서 실행이 가능하다.
Android Library
이 모듈은 빈 패키지로 생성되며, 위의 MainActivity 는 작성자가 생성해주었다. 이 것으로 보아 이 모듈은 전의 모듈과 비교했을 때 android 관련 라이브러리 즉, 코드(?)는 사용가능하지만 독립적으로 실행시키지는 못하는 차이점이 있는 것 같다.
Kotlin Library
이 모듈은 Activity 즉, 안드로이드 프레임워크에 종속된 클래스를 만들지 못한다. 완전 독립적으로 Kotlin 코드만 작성이 가능한 모듈로 보인다.
그렇다면 이제 위의 세 가지 모듈의 특징을 (완전히 다 파악한 것은 아니지만) 가지고서 Presentation, Domain, Data Layer 의 특징을 접목해 어떤 모듈에 어떤 레이어가 들어가야할지 생각을 해보자.
그 전에 더 큰 범주에서 Multi Module Architecture 를 설계하는 큰 이유 중에 하나가 바로 공통된 코드부분을 삭제하고, 하나로 관리하는 데에 있다. 이 관점에서 처음에 보여준 예시 사진을 다시 봐보자.
core 혹은 common 이라는 모듈은 전체 프로젝트에서 반복적으로 사용되는 코드들이 포함될 것 같다. 예를 들면...DI 관련 코드라던가 Navigation 관련 코드이지 않을까 생각한다. 이 부분은 코드를 작성하면서 반복되는 부분이라면 점차 하나씩 해당 모듈에 포함시켜주는 식으로 작업하게 되지 않을까 싶다.
core-ui 혹은 common-ui 이 모듈에는 아마 공통적으로 사용되는 컴포넌트 ui 가 포함되지 않을까 생각한다. composable fun. 즉, 커스텀으로 작성한 MainButton(), UnderLineTextFeild() 와 같은 형태의 파일들이 속하게 될 것 같다.
buildSrc 모듈은 아직 잘 모르겠다. 무언가 Gradle build 와 관련된 어떤 코드들이 포함되지 않을까 싶은데 아직은 사용해본적이 없는 코드라 일단은 넘어가야겠다.
app 모듈은 딱 User Interface 부분이라고 생각한다. Activity 혹은 Fragment 파일들이 속해 실제로 running 되는 application 모듈이 될 것 같고
마지막으로 각 feature 별로 모듈을 생성하고, 그 하위에 필요에 따라 data, domain, presentation 모듈을 생성한다.
Data Layer 에는 해당 feature 에서 외부/내부에 저장하는 형태의 데이터 엔티티를 정의하고, mapper 클래스 정도가 포함이 될 것 같다. 또한, MVVM 패턴에서 사용하는 Repository 구현체도 당연히 포함된다.
Domain Layer 에는 실제 앱에서 필요한 데이터 형태를 정의, Repository, UseCase 등이 포함된다.
Presentation Layer 에는 View 와 ViewModel 이 포함된다.
이렇게 하면 추가적으로 core 모듈에 외부 혹은 내부 DB 에 접근하는 코드가 포함되지 않을까 싶다. 왜냐하면 기존에 단일 모듈 + Clean Architecture 프로젝트라고 가정하면 Data Layer 에서 DB 에 접근하는 코드를 사용하는데 각 feature 별로 이 코드들이 중복되니 해당 코드가 core 모듈에 포함되지 않을까 생각한다. (지금은)
일단, 처음이기 때문에 모듈 및 패키지들을 작성해본 후에 개발을 실제로 진행하면서 무언가 MMA 나 Clean Architecture 를 해치는 코드가 보이면 그 때 다시 생각해봐야겠다...
