멀티 모듈에서 대거를 어떻게 적용해야 하는지에 대한 발표

1. Dagger with Multi-Modules
Created by Ethan.Yoo

2. 구글 샘플 리뷰

3. Google Multi module dagger sample
https://developer.android.com/training/dependency-injection/dagger-multi-module

4. Google Multi module dagger sample
App, Feature 모듈은 Component로 새로
그래프를 만듬
Core는 Module 만 제공

5. Google Multi module dagger sample
모듈마다 다른 Scope을 갖는 디펜더시 그래프를 갖고 싶다면 Component를
만들고,
그렇지 않다면 Module만을 제공

6. Google Multi module dagger sample
Subcomponent를 기반으로 구현하였음. (Component를 기반으로 만들 수 있지만, Subcomponent가 더
묵시적인 DI 그래프 작성이 가능)
Subcomponent를 사용하면 안드로이드의 피쳐 모듈에서 어떻게 Subcomponent의 인스턴스에 접근 할 수
있을지 고민이 필요. Subcomponent 의 생성을 위해서는 AppComponent의 인스턴스가 필요.
AppComponent는 :app 모듈에서 생성. 피쳐 모듈은 기본적으로 :app 모듈에 접근 할 수 없음.

7. Google Multi module dagger sample
구글은 ApplicationContext에
인터페이스를 넣는 방식으로 구현.

8. DaggerMultiModuleApp 리뷰

9. :app:honeyscreen
:sdk:buzzscreen :sdk:benefit
:feature:lockscreen :feature:feed
:lib:auth :lib:ad
:lib:api-client
app
sdk
feature
lib
https://github.com/EthanYoo/DaggerMultiModule

10. 버즈빌 룰 논의

11. SDK 마다 RootComponent를 보관할 싱글톤 생성이 필수
구글은 ApplicationContext를 사용했고 일반적으로도 그러하지만 SDK는 그렇게 할 수가 없음.
따라서 SDK마다 RootComponent를 보관 할 싱글톤 객체가 하나 필요
현재 BS는 BuzzScreen 객체에 RootComponent를 보관 중

12. App or SDK Layer 에서 RootComponent 생성
디펜던시를 조립할 RootComponent는 최상위 레이어에서 생성한다.
DI를 한다는 것은 상위 모듈이 하위 모듈에게 필요한 인스턴스를 제공해준다는 의미인데, 결과적으로
상위 모듈은 하위 모듈과 하위 모듈이 제공받고 싶어하는 구현체를 모두 알아야 함. 이는 참조 관계나
구조적으로 봤을 때 최상위 레이어에서 RootComponent를 구현하는게 적절함.
비슷한 이야기로 app layer가 모듈간의 조립을 담당한다는 아티클이 많음.

13. App or SDK Layer 에서 사용하는 모든 모듈을 참조
RootComponent를 대거에서 generate 할 때 사용하는 모든 feature, lib의 참조가 일어남. 즉,
implementation을 사용하는 모든 module에 대해서 해주어야 함.
예시) app ← feed ← api-client 이런식으로 참조 관계가 있으면 app이 api-client에도 접근이 가능해야
함. implementation으로 직접 참조하거나 api를 사용해서 디펜던시 접근을 app까지 열어야 함
툴의 도움을 받으면 자동으로 app layer에서 사용하는 모듈의 참조를 적용할 수 있음. 묵시적인 단점.
자신의 하위 모듈에게 제공할 디펜던시
관계를 만들기 위해서 모든 모듈을 참조
하여야 함.
실제 접근하는 코드가 없어도 대거가
generate 해버림
generate되는 곳이 rootComponent가 있는
위치여서 결국 app or sdk 모듈에 모든
디펜던시의 참조가 필요

14. :app:honeyscreen
:sdk:buzzscreen :sdk:benefit
:feature:lockscreen :feature:feed
:lib:auth :lib:ad
:lib:api-client
app
sdk
feature
lib
https://github.com/EthanYoo/DaggerMultiModule

15. :app:honeyscreen
:sdk:buzzscreen :sdk:benefit
:feature:lockscreen :feature:feed
:lib:auth :lib:ad
:lib:api-client
app
sdk
feature
lib
https://github.com/EthanYoo/DaggerMultiModule

16. Feature or Lib Layer 에서 디펜던시를 제공하는 방법
대거로 디펜던시를 제공하는 방법에는 4가지 정도가 있음
- @Inject 생성자
- @Module
- @Component 디펜던시
- @Subcomponent
이 중 @Inject, @Module은 자신만의 Scope을 표현 할 수 없음. 이를 이용해서 그래프를 만드는
Component or Subcomponent에서 Scope을 표현
즉, 디펜던시 제공하는 방법은 크게 다음 2가지 카테고리로 나뉘어짐
- Scope 없이 제공
- @Inject 생성자
- @Module
- Scope 포함해서 제공
- @Component
- @Subcomponent

17. Feature or Lib Layer 에서 디펜던시를 제공하는 방법
의견 : Lib의 경우 자신이 Scope을 가질 이유가 없어 보임. 사용하는 모듈에서 자신의 Scope에 맞게
조립을 하는게 맞다고 생각. 따라서 App은 Component, Feature는 Subcomponent, Lib는 Module 을
구현해서 제공하는게 옳아 보임.
● App → Root Component
● Feature → Feature SubComponent
○ Component의 본질은 분리된 디펜던시 그래프의 스콮을 갖고 싶은지에 대한 문제라고 생각
○ 가능하면 Component는 적으면 좋다고 생각하지만 Feature의 경우에는 피쳐 별로 그래프가
분리되는게 맞다고 판단
● Lib → Lib Module
○ Lib 같은 경우에는 별도 Scope이 필요 없도록 짜는게 맞다고 생각
○ 때문에 Module or constructor inject로 제공

18. Feature or Lib Layer 에서 디펜던시를 제공하는 방법
Component Subcomponent
처음 셋팅할 때 모든 컴포넌트를 새로 정의해줘야 하는 Component 방식보다
상위부터 하나씩 정의하는 Subcomponent 방식이 더 깔끔하다고 생각

19. Qualifier 참조 관계
● 자신이 주입받을 객체의 Qualifier를 지정하기 위해서는 하위 모듈에서 상위 모듈의 Qualifier를
알아야 함
○ 예시
i. Feed - Ad 모듈 관계가 있을 때 Feed에서 @UnitId 를 명시하면 Ad에서 @UnitId를 주입
받고 싶은 경우. @UnitId라는 Qualifier를 서로 다른 2개의 모듈에서 동시 참조가 필요
● 의견
○ dagger-base 모듈을 만들고, core 레이어에 넣는다.

20. dagger-base 모듈
● dagger 라이브러리의 헬퍼 모듈. 전 모듈이 참조하는 것으로 한다.
● core 레이어로 봐도 무방해보임
● 전 모듈에 대해 dagger 모듈을 api 레벨로 제공하는 것도 고려. 3rt-party-lib인 dagger는 api로
제공해도 괜찮을 것 같다.

21. 디펜던시 관계에 대해 그래들 스크립트
● Root에서 각 레이어의 모듈에 대한 script template을 제공하는게 좋아 보임
○ 새로 모듈을 만들 때 공통의 script를 Root에서 configure 해주는 방향.
○ 각 레이어를 :app, :feature, :lib 등의 접두사로 구분 할 수 있으니 레이어별로 다른 공통 설정
제공 가능