이번에 위치추적모듈 프로젝트를 진행하면서, API와 Batch의 로직들을 단일 모듈에서 운영하면서 스파게티 코드, 의존성 덩어리, 설정 등 여러 가지 문제가 발생하였다. 그래서 멀티 모듈로 전환하게 되었다. 이번 게시글에서는 멀티 모듈로 전환하며 느낀 점들을 정리해보도록 하겠다.
1. 게시글 추천
멀티모듈로 전환할 때 도움을 많이 받은 게시글들이다. 한 번쯤 읽어보는 것을 추천한다.
- 멀티모듈 쓰지 말자
- 멀티모듈 설계 이야기 with Spring, Gradle
- [Server] 멀티 모듈을 설계하는 관점과 고려사항 with Spring & Gradle
- 왜 프로젝트를 멀티 모듈로 구성할까
2. 프로젝트 구조
멀티 모듈로 전환한 프로젝트의 구조는 아래와 같다.
프로젝트의 폴더명은 망나니 개발자님의 폴더명 사용하였다. 하지만 프로젝트 구조의 구성 요소들은 권용근님의 게시글을 참고하여 구성하였다. 그림으로 정리하자면 아래와 같다.
사진을 이용하여 간단히 설명하자면 아래와 같다.
2-1. utils
- Type
2-2. core:domain
- Domain
- Repository
- Domain Service
2-3. core:infra
- client
2-4. Server: api & Batch
- batch Server
- api Server
3. 생각 정리
일단 멀티모듈로 전환한 목표인 Api와 Batch의 Server 분리는 이루었다고 생각한다. 이로 인해 기능 구현과 테스트 코드 작성이 편리해졌고, 리소스 관리 및 배포 과정에서도 수월했다.
처음 멀티모듈을 구성할 때에는 common 폴더를 이용하여 Api와 Batch에서 공용으로 사용하는 코드를 모아놓고 멀티모듈로 구성하고자 하였다. 하지만 전환하면서 느낀 점은 이대로 가면 유지보수가 더 어려워지겠다는 생각이었다. 해당 내용의 PR은 아래에서 볼 수 있다.
PR 내용에서 알 수 있듯이, 흔히 말하는 Common의 저주에 빠지게 된 것이다. 여러 가지 게시글들을 참고하여 현재의 구조로 구성하게 되었는데, common 폴더만을 이용하는 것보다는 규칙을 두고 폴더를 구성하여 스파게티 코드, 의존성 덩어리, 설정 등의 문제를 해결할 수 있었다.
하지만 솔직히 아직까지의 프로젝트 크기로는 크게 체감되지는 않는다. 추후 더 큰 프로젝트를 진행하며 현재 멀티모듈 구조의 장점을 몸소 느끼고 싶다는 생각이 크다. 물론 현재 구조에서 틀린 점이 분명히 있을 것이고, 다양한 프로젝트를 진행하며 개선해나갈 생각이다. 단지, 지금은 현재 구조로 만족한다.
