멀티 모듈 설계 고민

잘못된 모듈 설계

19년도에 만들고 있던 개인프로젝트를 멀티모듈프로젝트를 진행했었다. 대충 기억을 되짚어보면 아마 front-end, admin-api, pay-api, common 뭐 이런식으로 모듈을 구성하였던 것 같다. 그리고 이런식으로 구성한 모듈이 우아한형제들 블로그에 올라온 글에서 실패한 설계의 예로 쓰이고 있음을 알게되었다.

그 때 개인프로젝트를 예시로 좀 들어보면 이렇다. A,B,C,D,E 모듈이 있다. C에 API가 하나가 작성되었고 이 API를 D, E 서버가 사용해야 한다고 가정해보자. API의 응답 및 요청 DTO들이 생겼다. 이걸 D, E 서버에 모두 넣어야 할까? 그럼 중복으로 코드를 작성하고 관리하기 힘들테니 common에 작성을 해놓는다. 자연스럽게 A, B도 common을 사용하고 있으니 이 DTO를 들고있게된다. 필요한 기능을 담은 라이브러리 하나를 만들었다. 근데 이게 A,B,C,D 모두가 사용해야한다. 위와 같은 이유로 common에 작성을 하였고, E서버는 의존을 가질 필요없는 라이브러리를 지니게된다. 

신규 프로젝트

이번에 새로운 프로젝트를 진행하게 되었는데 멀티 모듈 프로젝트로 구성하려고 한다. 이번에는 같은 실수를 반복할 수 없다! 이번에 새롭게 설계한 모듈은 아래와 같이 구성하였습니다.

간단하게 각 모듈을 설명하자면 일단 A, B는 독립적으로 실행가능한 모듈입니다. 독립적으로 실행가능한 모듈은 내부적으로 app, domain, client를 지니고 있습니다.

App Module

app 모듈은 시스템의 비즈니스 로직을 담당하고 있는 클래스들을 모으려고 합니다. 예를 들면 고객으로이 주문한 상품의 재고가 있는지 체크하고 결제전 쿠폰 적용을 한 가격을 결제한다 등의 비즈니스적인 로직들을 모아놓습니다. app을 좀 더 깊게 구분하면 web, batch 기타 서비스 등으로 나눌 수 있을 것 같습니다. 이렇게 나눈 이유는 web, batch 각 서버의 특징에 따라 디펜던시들이 달라질 것이라 생각했기 때문입니다. web에는 웹과 관련한 디펜던시(web, security 등)가 존재할 것이고, batch에는 이런 의존성들이 필요없기 때문입니다. 

Domain Module

도메인 모듈은 시스템의 핵심이 되는 도메인과 그 도메인을 다루기 위한 서비스들을 모아놓았습니다. 도메인도 좀 더 상세하게 나누면 우아한형제들의 글에 나온것처럼 domain-rdb, domain-nosql 등으로 나눌수 있을 것 같습니다. 여기서 고민을 많이 했던건 서비스 범위였습니다. 비즈니스 로직이 조금이라도 들어가는 서비스가 있다면 가차없이 app 모듈로 넘겼고, 오로지 도메인만을 다루는 서비스 클래스만을 이 모듈로 옮겼습니다.

Client Module

클라이언트에는 애플리케이션을 사용하기 위한 클래스들을 모아놓았습니다. 우아한형제들 글에서 client 모듈을 상위 모듈로 올리고 {서버}-{서버}-client 형식으로 서버간에 공유되는 클래스들을 모아놓았는데 저는 API 단위로 클라이언트 모듈에 서브모듈을 추가할 생각을 하고 있었습니다. 예를 들어 주문 API, 조회 API 등이 있다고 가정을 한다면 A-Order-Client , A-Search-Client 등으로 모듈을 만들고 사용하는 서버에서는 사용할 API에 대한 모듈만 사용하면 될 것 같습니다.

Shared Module

흔히 말하는 common 모듈입니다. 내부적으로 domain을 하나 들고 있는데 시스템 전체에서 사용이 되는 도메인을 이 부분에 넣습니다. 예를 들면 토큰? 이런게 있을수 있겠네요. 내부는 도메인 모듈처럼 domain, repository, service 등으로 구성합니다. 그 외에 전체적인 시스템에서 공통적으로 사용할만한 클래스들을 shared 모듈 밑에 추가하려고 합니다. 예로 util이 있을 수 있을것 같아 위 구성도에 추가해보았습니다.