효율적인 모듈 분리

*아래 모듈의 네이밍에서 server → 서비스명으로 생각하면 된다!

server-common : 공통 모듈 계층

제약이 가장 많은 계층

사용하는 시스템이 하나로 국한되지 않고, 다른 프로젝트에서도 가져와 사용할 수 있는 모듈로, 다른 모든 모듈이 해당 모듈을 의존하므로 여기서는 다른 모듈을 의존하지 못한다. (서로 의존하는 관계가 된다면 순환 참조 문제가 발생할 수 있으므로)

• Type, Util 등을 정의
• 가능하면 사용하지 말자!

server-core, server-domain : 도메인 모듈 계층

하나의 도메인 모듈은 하나의 infrastructure에 대한 책임만을 가진다.

만약 2개 이상의 infrastructure를 사용하는 상황이라면, 아예 책임을 가지지 않도록 해야 한다.

예를 들어, User 엔티티에서 User 객체 자체를 저장하는 RDB와 리프레시 토큰을 저장하는 Redis 2가지의 infrastructure를 사용할 때 2개의 의존성을 모두 추가해버리면 엄청나게 관계가 꼬여버리게 될 것이다. 따라서 아예 책임을 지지 않도록 하여, 2개의 infrastructure 간의 관계가 생길 때 2개 모듈(domain-redis, domain-rds)을 품는 모듈을 작성하거나, 2개 infrastructure 모듈을 품는 어플리케이션에서 처리하는 방법이 있다.

• 도메인 모듈을 조합하여 더 큰 단위의 도메인 모듈을 만들 수 있다
• 서비스 로직을 모른다

📎 도메인 모듈의 책임

1. Domain

   도메인 클래스 (테이블과 매핑되는 엔티티 클래스)

2. Repository

   도메인의 CRUD 기능

3. Service

   도메인 로직 → 트랜잭션 단위, 요청 데이터 검증, 이벤트 발생 등을 처리

server-client, core-web, server-event-publisher : 내부 모듈 계층

저장소, 도메인 외 시스템에서 필요한 모듈

ex. 푸시알림 이벤트 전송, 소셜 로그인 외부 클라이언트로부터 받아온 정보 처리

→ 독립 모듈 계층과 비슷한 역할을 하지만 가장 큰 차이는 시스템에 연관이 있는 모듈이라는 점이다.

• 어플리케이션, 도메인 로직을 모른다
• 도메인 계층과 분리 (의존X)

📎 주요 구성

• server-client 외부 시스템과의 통신을 책임 → 비즈니스 로직과 관계 없이 요청, 응답에 필요한 사용성 제공 및 설정 구성
  
• core-web web 설정을 사용하는 프로젝트에서 사용하는 모듈 → Web Filter를 이용한 보안, 로깅 등으로 활용 및 필수적인 공통 설정 구성 → 우리 서비스에서는 아마 사용 X
  
• server-event-publisher 특정 이벤트에 대한 처리 담당 → 이벤트 발생 시 SQS로 이벤트 전송, 로그 기록 등의 특정 행위를 처리
  

server-app-xxx : 어플리케이션 모듈 계층

하위의 모듈들을 조립하여 독립적으로 실행가능한 계층

‘app’이라는 네이밍을 넣어서 모듈 내의 실행가능한 어플리케이션을 명확히 한다

• 모든 모듈에 대한 의존성을 가지고 사용 가능하다

server-external : 독립 모듈 계층

시스템과 연관이 없는 완전히 분리된 계층

ex. 소셜로그인에 필요한 외부 클라이언트 설정, 파이어베이스 연결 설정

• 다른 서비스에서도 그대로 해당 모듈을 가져다 쓸 수 있다

[결론] 👨‍👩‍👧‍👦 엄빠도 어렸다 에서는?

• umbba-api, umbba-notification : 어플리케이션 계층

• umbba-domain : 도메인 계층

• umbba-common : 공통 계층

• umbba-external : 독립 계층

위와 같이 API서버, 알림서버를 분리하여 두고 해당 어플리케이션에서 하위 세 개 계층의 모듈을 불러와 사용하는 것으로 결정!

참고자료

멀티모듈 설계 이야기 with Spring, Gradle | 우아한형제들 기술블로그