도입 이유

기능별 명확한 분리

• 주문 모듈, 상품 모듈, 메세지 전송 모듈등 여러가지 기능별로 분리하여 관리 가능
• 위처럼 기능별로 모듈을 분리 함으로써 각각의 jar 파일로 서버에 띄울수 있음.
• 각 기능별로 성격이 다르므로 공통된 의존성이 별로 없이 각각 최소한 의존성으로 분리시킬 수 있음.

기능별 모듈 분리로 얻는 장점

• 멀티모듈의 기능들은 독립적이며 각자 필요한 최소 의존성을 가지고 있기 때문에 재사용에 용이하다.
• 한가지 기능의 수정으로 모든 프로젝트를 빌드 할 필요가 없다. 수정한 기능 모듈만 리빌드 하자.
• 디버깅에 용이하다. 버그가 발생했다면, 전체시스템이 아닌 버그발생 모듈만 검토하자.

멀티모듈 단점

• 여러 개의 서비스 모듈을 하나의 JVM에 띄우기 위한 추가 작업이 필요.
• 서비스 모듈별 설정파일과 패키지 의존성 관리에 신경을 써야한다.
  ex) 주문모듈 에서 주문완료 후 메세지 전송을 위해 메세지 전송 모듈을 호출 한다. 이때 MessageService 빈을 들고와서 처리한다면 의존성이 엮이게 되는 것.

물론 멀티모듈을 사용하면서 RestTemplate 또는 WebClient 를 사용해서 모듈간 api 호출이 가능하나, 이럴경우 데이터 동기화 이슈가 생길 수 있다.

향후 프로젝트가 확장된다면 ?

• 기존 모놀리틱한 프로젝트의 멀티모듈 구조가 사용자 급증으로 인하여 MSA 구조로 변환이 요구될 때 멀티모듈 구조로 구성된 프로젝트는 하나의 모듈을 하나의 서버로 변경함으로써 쉽게 구조변경이 가능하다.
• 멀티모듈이 아닌 싱글모듈로 이루어진 프로젝트는 확장시 다시 기능별로 프로젝트를 분리해야하는 업무의반복이 이뤄져야 한다.

이렇게 하나의 모듈을 하나의 서버, 즉 인스턴스로 관리하게 되면 서비스별로
각각의 JVM에서 서비스가 돌아가는 구조가 된다.

이것을 Micro Service Architecture (MSA) 라고 한다.

MSA로 프로젝트를 구성한다면 서비스별로 Scale Up에 용이하고, 서비스간 의존도가 가장 낮은 구조이기에 유지보수가 편리하다.

다만 서비스 간 통신에 많은 신경을 써야하며
데이터 동기화 이슈, 메세지 큐 관리, 서킷 브레이커, 로드밸런싱, 분산 DB, 서버간 트랜잭션 처리 등 넘어야할 허들이 많다.

앞으로 이러한 키워드들을 바탕으로 스터디를 진행하여.
각각 섹션별 블로깅을 ... :(