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 두는 방법

• https://daddyprogrammer.org/post/13156/spring-boot-change-multi-module/
• https://velog.io/@haerong22/IntelliJ-%EB%A9%80%ED%8B%B0-%EB%AA%A8%EB%93%88-%ED%94%84%EB%A1%9C%EC%A0%9D%ED%8A%B8-%EB%A7%8C%EB%93%A4%EA%B8%B0
• https://velog.io/@mu1616/java-gradle-%EB%A9%80%ED%8B%B0%EB%AA%A8%EB%93%88-%ED%94%84%EB%A1%9C%EC%A0%9D%ED%8A%B8-%EA%B5%AC%EC%B6%95%ED%95%98%EA%B8%B0

root build.gradle 없는 방법

• https://docs.gradle.org/current/userguide/multi_project_builds.html
• https://docs.gradle.org/current/userguide/declaring_dependencies_between_subprojects.html

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

에러 정리

• plugin-request-for-plugin-already-on-the-classpath-must-not-include-a-version 에러 뜰 때
• 패키지가 다르면 jar를 disable하면 못찾는다.
• sub module 구성하면서 Intellij의 Project Structure가 꼬인 경우(없는 모듈을 잡는다거나 중복해서 잡는다거나) settings.gradle에서 rootProject.name 변경해서 다시 잡아줄 것

Gradle implementation 과 compile(api)의 차이

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

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