현재 진행 중인 프로젝트에서는 유튜버 정보와 유튜브 영상 정보가 DB에 저장되어 있다. 이 데이터를 일정 주기로 업데이트 해야하는데, 이를 매 시간마다 수행하면 리소스 낭비가 심할 것 같았다. 따라서 하루에 한 번씩 스프링 배치를 활용해 DB에 쿼리를 날리는 방안을 선택하였다.
그러나, 이 배치 서비스를 하나의 프로젝트 안에서 별도의 패키지로만 구성한다면 나중 API 트래픽이 높아질 때 해당 API 부분만을 확장하는데 어려움을 겪게 될 것이라는 생각이 들었다. 또한 배치 작업은 하루에 한 번 데이터 업데이트만을 수행하기 때문에 확장의 필요성을 크게 느끼지 못했다. 이러한 이유로, 각 모듈의 확장을 독립적으로 수행할 수 있는 멀티 모듈 구조를 도입하기로 결정하였다.
멀티 모듈이란 하나의 서비스나 프로젝트를 여러 개의 모듈로 나누어 개발하는 것이다.
Java에서 모듈이란 패키지의 한 단계 위의 집약체이며, 독립적으로 배포될 수 있는 코드의 단위를 이야기 한다.
이 방식의 적용으로 각 모듈은 자체적인 책임을 가지며, 개발 및 유지보수가 더욱 편리해진다.
또한, 모듈간의 명확한 경계가 생겨 나중에 시스템을 확장할 때도 유연하게 대응할 수 있다.
우리 프로젝트에서는 API 모듈, Batch 모듈, 그리고 Domain 모듈로 나뉘어져 있다. 처음에는 어떤 기준으로 모듈을 나누어야 할지 많이 고민했었다. 하지만 최종적으로 현 구조를 통해 여러가지 장점을 깨닫게 되었다.
API와 Batch 모듈이 Domain 모듈에 의존하는 형태로 설계되었다.
API 모듈 : 사용자 인터페이스를 담당하는 Controller와 Service 계층, 그리고 DTO와 Repository가 있다.
Domain 모듈 : Entity가 계층이 있다.
Batch 모듈 : 이 모듈에는 배치 서비스가 담겨 있다.
중복 코드 최소화 : Domain 모듈에 공통적으로 사용되는 비즈니스 로직이나 Entity 클래스를 모아두면, 중복 코드를 줄일 수 있어 코드 관리가 편리해진다.
간편한 유지보수 : 각 모듈이 각각의 책임을 가지고 있어, 특정 기능의 수정이나 확장이 필요할 때 해당 모듈만을 대상으로 작업을 진행할 수 있다.
각 모듈의 역할과 책임 명확 : 예를 들어, 우리 프로젝트에서 batch 모듈을 수정해야 하는 신입 개발자가 있다면, 그는 전체 프로젝트를 이해할 필요 없이 build.gradle 파일에서 관련 모듈만을 파악하면 충분하다.
의존성 최소화 : 의존성을 줄이게 되면, 변경에 따른 영향도가 줄어들며, 결합도가 낮아진다. 이로 인해 각 모듈을 가볍게 유지하면서 빌드 시간을 줄이고 생산성을 향상시킬 수 있다.
https://dundung.tistory.com/243