[Spring] 멀티모듈의 개념

멀티모듈, 단일 프로젝트로하면 어떤 장점이 있을까?

왜 굳이 멀티 모듈을 두는것일까?

시스템적으로 보장이되고, 빠른 개발 사이클을 가질 수 있다.

 

멀티모듈과 MSA가 어떤 연관이 있을까?

 

MSA에서는 분리와 병합이 자주된다.

시스템의 분리,통합을 유연하게 만들어줄 수 있는 좋은 아키텍처를 만들 수 있다.

 

클린 아키텍처라는 책에서는 모놀리틱과 msa적인 변경이 자유로운 아키텍처가 좋은 아키텍처라고 얘기한다.

 

대부분 공통화된 코드를 분류해서 뽑아내려고하면 공통화된코드를 Common으로 모은다.

그러면, common이 계속 커지면서 개발하기 힘들어진다.

 

1. 스파게티 소스가 된다. Common이 커지면서  영향범위가 점점 커지기 마련이다.

즉 스파게티 소스가 되고 분리가 어려워진다. 쉽게 말하면 뭐가 뭔지 모르게된다.

 

2. 의존성이 common에, 몰리면서 의존성 덩어리가 생성이된다.

즉 의존성이 충돌이 되고 점점 하나의 의존성이 여러 모듈에 영향을 미치게 된다.

 

3. 공통 설정

Common에서 설정을 직접 주입을 하고 사용을 하게 되면, 여러 모듈에 대한 

설정이 공통화 되어 문제가 발생한다.

즉 이말은 아래와 같다. 예를 들어 어떤 시스템에 대해서 100스펙의 모듈을 사용하도록 공통에서 설정을 관리한다면

공통으로 설정값을 참조하는 모듈들은 필요이상으로 100스펙의 시스템을 물고있게 된다.

따라서 공통으로 설정을 관리하게 되면, 필요이상의 자원 낭비가 발생한다.

 

 

따라서 계층으로 설게를 하고, 해당 계층별로 역할,책임을 분리하는 것이 좋다.

레이어드 아키텍처, 헥사고날 디자인 패턴이 해당 골머리를 앓고있는 사람들에게 좋은 대안이다.

 

이건 좀 다른 얘기인데, 이런식으로 아키텍팅을 하는 사람들도 있다.

어플리케이션 계층에서 내부모듈, 도메인 모듈로 나누고, 공통 모듈로 나눈다.

또한 외부 시스템과 연동하는 모듈은 외부 독립적으로 모듈로 나누게 되는 것을 볼 수 있다.

이렇게 되면, 사용 추적 및 스펙 변경에 대한 단일 변경 포인트에 대한 장점을 가지게 된다.

 

좀 더 여러가지 효용성은 뒤에, 실제 구현을 하면서 느껴보도록하자,