멀티모듈 프로젝트로 전환
프로젝트 진행 중에 단일 모듈 단일 프로젝트에서 멀티모듈 프로젝트로 전환했습니다. 전환을 결정한 이유는 크게 두가지입니다.
-
이번 프로젝트의 요구사항은 카프카를 사용한 이벤트 기반의 구조를 구현하는 것입니다. 애플리케이션 외부의 메시징 플랫폼을 사용한다는 것은 서비스의 분리를 전제로 합니다. 향후 서비스 분리를 용이하게 하기 위해 모듈을 분리했습니다.
-
앞서 (01. JPAREPOSITORY ) 객체뿐 아니라 패키지와 계층 사이의 의존성을 고려하면서 개발하는 연습을 하고 있습니다. 모듈을 분리하고 빌드파일에 모듈간의 의존성을 명시적으로 제한한다면 이러한 연습에 도움이 될 것이라 생각했습니다.
모듈을 어떻게 분리할까?
현재 프로젝트를 모듈로 어떻게 나눌까 고민하면서 찾아봤을 땐 모든 것이 그렇듯 각자 생각하는 모듈의 정의와 분리하는 방법들이 다양했습니다. 하지만 공통적으로 모듈을 하나의 프로그램 속에서 협력하는 하나의 큰 객체로 보고 있었던 것 같습니다.
객체의 책임은 크게 하는 것과 아는 것 두가지의 범주로 나뉩니다. (조영호, (2015), 객체지향의 사실과 오해). 객체로서 모듈을 하는 것과 아는 것을 기준으로 나눠보려고 했습니다.
.
├── application
│ ├── app-auth
│ ├── app-image
│ ├── app-kafka
│ ├── app-mail
│ ├── app-pet-command
│ └── app-pet-query
├── domain
│ ├── domain-outbox
│ ├── domain-pet-command
│ └── domain-pet-query
├── infrastructure
│ ├── infra-jpa
│ ├── infra-kafka
│ ├── infra-redis
│ └── infra-repository
└── presentation
├── pre-auth
├── pre-image
├── pre-pet-command
└── pre-pet-query처음으로 모듈을 나누다보니 패키지 단위와 유사하게 나눠졌습니다. 현재 프로젝트 규모에 비해 너무 지나치고 과연 독립적으로 배포될 수 있는 단위인가 하는 의문이 들었습니다.
최종
├── domain
├── infrastructure
├── pet-command
├── pet-query
└── side-car최종적으로 나눈 프로젝트 구조는 위와 같습니다. 여러가지 Data Source와 이를 사용하는 패키지별로 모듈을 나눠야 하지 않을까하는 생각이 들었지만 우선은 모듈을 나누고 빌드와 의존성을 관리하는 연습에 집중하기 위에 위와 같이 5개의 모듈로 나눠보았습니다.
pet-command는 명령 모델, 현재는 강아지에게 투표하는 기능을 담당합니다. pet-query는 강아지 목록과 특정 강아지 조회를 담당합니다. side-car 모듈은 이벤트를 수신하여 조회 모델을 생성하여 redis에 저장하고 이미지호스팅, 이메일 인증 등의 기능을 가집니다.
의존성의 방향
side-car
