• root proejct 하나의 하위에 sub module 여러 개를 두는 방식이 상호 import하기 좋다.
  • 멀티 모듈로 만들기 전에 참고 - https://techblog.woowahan.com/2637/   
    • 여기 나온 사례의 문제점은 common의 의미를, "2개 이상 쓰는 곳이 있다면 common에 넣자"라고 생각해버려서, common이 너무 비대해졌다는 점.
    • common은 모듈 전역적으로 적용되거나 독립 모듈로 구성하기 애매한 것들만 넣고,
    • 나머지는 비즈니스 로직 별로 독립 모듈로 쪼개야 common이 비대해지는 것을 막을 수 있다.
    • plasma-benefit/posts/485  이 사례도 참고해볼만 하다.

 

멀티 모듈, 서브 모듈로 구성했을 때의 장점은?

  • X 관심 분리를 통한 스파게티 코드 방지, 변경 범위 축소 -> 패키지만 나눠도 가능하다.
  • O 독립된 모듈(library)로서 여기저기서 가져다 쓸 수 있는 확장성
  • O 독립된 jar로 패키징하므로 별도의 main 가지고 단독 실행 가능
  • O 모듈 별로 사용하는 의존성을 다르게 관리 할 수 있음 (게다가 버전도 다르게 갈 수 있다.)
    • 모듈이 나뉘어져있지 않고 패키지만 나뉘어진 구조에서 시스템이 비대해졌다면, 의존성 버전 하나 바꿀 때 테스트 해야 하는 범위가 너무 커질 수 있음. 
  • X 단독 실행을 위해 패키징 하는 경우 jar 용량 감소 -> 어차피 용량이 커지는 주 요인은 라이브러리인데, 서브 모듈도 단독 실행을 위해 라이브러리를 포함해서 패키징 한다면 용량이 드라마틱하게 절감되지는 않는다.
  •  구동 속도 향상 -> 기본적으로 jvm 환경에서는 초기 구동 속도가 빠른 편은 아니지만 서브 모듈이 framework 사용하지 않는다면  단독 실행 시 1s 이내 수준으로는 만들 수 있다.

 

root build.gradle 두는 방법

 

root build.gradle 없는 방법

 

 

에러 정리

 

Gradle implementation 과 compile의 차이

  • common 모듈에서, import 시 `` implementation 'coroutine'`` 으로 하게 되면
    • common 모듈을 가져다 쓰는 곳에서 어떻게 import하든, coroutine 모듈의 내용이 보이지 않는다.
  • 반면 common 모듈에서 `` compile 'coroutine'`` 하게 되면
    • common 모듈을 가져다 쓰는 곳에서 coroutine 모듈의 내용이 보인다. (따라서 별도 임포트 필요 X)