Post

Intellij Multi Module Project 구성하기 (with Gradle)

멀티 모듈 구성하기 전 참고

멀티 모듈 구조가 현 상황에 도움이 되는 것이 맞는지?를 먼저 따져보아야 한다.ㄴ

패키지, 모듈, 서버 나누는 기준은? 참고

멀티 모듈 구조라면 Mono Repo 구조로

  • root project 하나에, 그 하위로 sub module 여러 개를 두는 방식이 상호 import하기 좋다.
    • 여러개의 sub module로 나누어서 개발하는 프로젝트라면 하나의 repository(모노레포)를 쓰는 편이 좋은데, 어떤 기능이 어디서 사용되는지 파악하기 쉽기 때문이다.
    • repo가 모듈 단위로 다 나뉘어져 있으면(멀티레포) 기능 수정 할 때 이 기능이 어디서 참조되는지 찾아내기 쉽지 않다.

멀티 모듈 참고 사례 (공통 모듈 관점에서)

  • https://techblog.woowahan.com/2637/
    • 여기 나온 사례의 문제점은 common의 의미를, “2개 이상 쓰는 곳이 있다면 common에 넣자”라고 생각해버려서, common이 너무 비대해졌다는 점.
    • common은 모듈 전역적으로 적용되거나 독립 모듈로 구성하기 애매한 것들만 넣고, (비즈로직이 아닌 것)
    • 나머지는 비즈니스 로직 별로 독립 모듈로 쪼개야 common이 비대해지는 것을 막을 수 있다.
  • plasma-benefit/posts/485 사례도 참고해볼만 하다.
  • https://share.navercorp.com/neday2022/lecture/1427158
    • core less 아키텍쳐의 장점과 그럼에도 코드 중복을 줄일 수 있는 방법에 대해 얘기하고 있다. (core가 아닌 supports)
  • 정리하면 공통 모듈이 아예 없는 것은 아니고,비즈로직이 아닌, “지원”, “유틸” 등에 속하는 것만 공통으로 뺄 수 있다.

멀티 모듈 구성하기

root build.gradle 두는 방법

root build.gradle 없는 방법

[!info] 이 방법은 공통으로 쓰이는 plugin 등이 중복해서 load 된다는 단점이 있다.
큰 문제는 아니지만 공통 설정을 명시할 root project나 common parent project를 두는 것이 나아보인다.

에러 정리

Gradle implementation 과 compile(api)의 차이

  • common 모듈에서, import 시 implementation 'coroutine' 으로 하게 되면
    • common 모듈을 가져다 쓰는 곳에서 어떻게 import하든, coroutine 모듈의 내용이 보이지 않는다.
  • 반면 common 모듈에서 compile 'coroutine' 하게 되면
    • common 모듈을 가져다 쓰는 곳에서 coroutine 모듈의 내용이 보인다. (따라서 별도 임포트 필요 X. 충돌 가능성 올라감.)
    • compile은 deprecated 되었고 api 로 바뀌었다.

[!info] 멀티 모듈 구조에서 yml은 각 모듈에서 직접 가지고 있는 형태가 좋다.

This post is licensed under CC BY 4.0 by the author.