멀티모듈매핑, 결합도 낮추기

멀티모듈은 서비스 레이어를 더 높은 차원에서, 물리적으로 나눈다는 생각이 든다.
그렇기에 의존성을 더 고민하고 나누어 놓을 필요가 있어 보인다😇

현재 프로젝트는 도메인 별로 모듈을 나누어 놓은 상태인데 고민의 흔적을 남겨 보고자 한다.

 

모듈 역할

들어가기에 앞서 모듈의 책임/역할에 대해 간략히 정리해 보자. 하나의 도메인에 대해 간략하게 두 개의 모듈로 나누어 두었다.

api module

• 외부와의 인터페이스 역할을 하며, HTTP 요청을 처리하고 응답을 반환을 처리

domain module

• 비즈니스 로직 및 데이터 모델을 관리
• 데이터 처리를 위한 Repository, Entity 등이 위치하며, 비지니스 로직을 다루기 위한 서비스 레이어도 포함한다.

 

왜 매핑을 고민할까?

결론만 말하면 모듈간 의존성을 낮추고자 하기 때문이다. 

더 나아가 별도의 서비스로 배포될 지 모르는 모듈들을 공통 클래스로 묶는다는 것은 결합도를 높일 것으로 보인다.

 

매핑 흐름

현재까지 구현한 구조로 예를 들어 보자.

review-domain을 사용하는 상위 모듈은 review-api이다.

만약 추가적인 모듈이 생성되게 되면 어떨까?
악성 리뷰를 삭제하는 관리자 페이지가 생기게 되면 추가로 admin-api가 생성될 수 있겠다.

그렇게 된다면 아래와 같은 의존성을 가지게 될 것이다.

review-api
+--review-domain
admin-api
+--review-domain

 

만일 아래와 같은 구조를 가진다면, 변경에 유연하게 대처하기 어려울 것이다.

request, response dto를 모두 하위 모듈인 도메인에 의존하여 반환하게 되면 변경이 생길 때마다 api 모듈의 반환값이 달라진다.
이처럼 review-domain 내의 dto를 공유하게 된다면, api 즉 ui에서 노출되는 값이 다를 때에도 별도 작업이 필요해진다.

애초에 웹에서 받는 request를 그대로 domain 모듈에 녹이게 되면 역할 분리가 모호하고, 결합도가 올라갈 것으로 보인다.

이를 방지하기 위해 다음 구조를 생각해 보았다.

각 모듈에서 반환되는 review-domain-dto를 각 모듈에 맞게 매핑하는 방법이다.

review-domain은 입력받은 domain-command로 도메인 로직을 수행하고, 결과를 domain-dto로 반환하면, 웹 계층에서 이를 가공하여(매핑) 유저에게 표현하는 방식이다.

장점 / 단점

장점으로는 앞서 말했듯이 모듈 간 의존성이 줄어 테스트가 용이하다는 점이 있다.

그러나 단점으로는 매핑이 과해진다는 점을 들 수 있다..
또한 서비스의 규모가 작고 요구사항이 간단하다면, 오히려 복잡도가 증가할 수 있을 것으로 보인다.

😊

멀티 모듈을 적용하며 해당 구조를 생각해 보았는데, 개선의 여지가 보이는 것 같다.
현재 읽고 있는 서적을 익히며 좀 더 보완해보려 한다.