멀티 모듈 설계 #2

최근 신규 프로젝트를 하면서 다른 프로젝트를 참고하다보니 모듈의 구조를 조금 바꾸어 보았다.
이전의 프로젝트에서 service모듈을 독립적으로 두었지만 모노레포방식으로 서버를 한 개 더 추가했을때 애매해졌다. 그 때의 경우에는 백오피스 서버를 하나 더 구축하는 것이었는데 비즈니스 로직이 공통부분의 로그인을 제외하면 거의 없을 정도 였다. 그래서 service 모듈이 하나 더 늘리다보니 모듈이 많아져 불편함을 느꼈고 이에 대해 부담을 느낀 동료는 나에게 백오피스 서버의 모듈만 controller-service를 통합하자고 제시했고 기존의 service모듈도 다시 통합하기에는 시간적인 부담이 있어서 기형적인 구조가 발생하고 말았다.

기존의 모듈 구조

controller - service - internal/external module - repository

service 모듈을 삭제하면?

1. core 모듈로 흡수
   core 모듈로 흡수된다면 QueryDsl를 사용하게되면 Service 역할이 모호해지는 경험이 한번씩 있을 것이다. 내부에서는 애매한 부분들이 모듈로 통합됨으로써 해결해보이는 듯한 느낌이 든다.

2. controller 모듈로 흡수
   이전의 프로젝트에서 일부 적용한 방법이며 controller-service가 1대1 대응하기에 모노레포형식의 서버를 한 개 더 추가했을 때도 완전히 분리가 된다. 또한 Open API 또는 인증 모듈을 독립적으로 만들어 각 서버에 필요한 모듈들을 붙임으로써 유연한 구조가 완성이 된다.

개선된 모듈 구조 (멀티 모듈 + 모노레포)

(server1) controller(service) - Authentication module - 
					          -     Open API   module -
                              -        S3      module -
                              -          ...          -  
--------------------------------------------------------     repository
(server2) controller(service) - Authentication module - 
                              -        S3      module -
                              -          ...          -           

독립성

각 서버에 필요한 비즈니스 로직만을 개발할 수 있고 사용하고 싶은 모듈만을 손쉽게 추가할 수 있다.

유연성

기본적으로 Authentication module를 통해 repository moudle를 알고있는 상태에서 controller에 필요한 모듈들만 추가함으로써 유연적인 구조로 완성이 되었다.

마무리

설계부터 다시 시작하다보니 멀티모듈의 최대의 장점을 이끌어내기 위해 개선을 해보았는데 실제 개발하는 과정에서 모듈 구조 개선할 필요성이 느껴지지 않을 정도로 안정된 구조라고 느껴졌다.
모듈의 역할과 책임에 대한 애매함이 없어짐으로써 더 빠르게 확신을 가지고 개발할 수 있게 되었다.