🟨 멀티 모듈 프로젝트
- 잘못 구성되면 나중에 변경할 때 힘들다. 🥹
- 프로젝트 초기에 이루어져야 하는 일련의 설계 과정
- 개발 생산성에 막대한 영향을 미친다.
- 무엇을 기준으로 멀티 모듈 프로젝트 구조를 나눠야 할까?
- Bounded Context
- 경계안에서 의미를 가질 수 있는 그룹을 정의한다.
- BOOT(Server), INFRA, DATA(Domain), SYSTEM(Cloud)
- 역할, 책임, 협력 관계가 올바른지 다시 한번 생각한다.
- Bounded Context
- 프로젝트가 커지고 있다면 다시 경계를 나누고 그 기준으로 소스 저장소를 분리
- INFRA(외부) 라이브러리에는 DATA 관련 구현을 지향(Anticoruption Layer)
- 서비스 구현은 각자 역할에 맞게 각각 구현될 수 있다.(공통으로 한쪽에 구현 x)
- 시스템 레벨 구현이 실제 서비스 애플리케이션과 밀접하게 연관되지 않도록 격리 or 전환(Istio)
🌿 Bounded Context
- BOOT(Server)
- 서버모듈(잦은 변화)
- batch, admin, api
- 서버모듈(잦은 변화)
- INFRA
- 연동모듈(큰 변화)
- and, vod, photo, billing
- 연동모듈(큰 변화)
- CLOUD(System)
- 클라우드(시스템)모듈(변화 적음)
- config, gateway, discovery
- aws, gcp, azure
- 클라우드(시스템)모듈(변화 적음)
- DATA(Domain)
- 데이터모듈(도메인)
- meta, user, chart
- 데이터모듈(도메인)
☠️ 멀티 모듈을 잘못 구성한다면 생길 수 있는 문제점
- Too many connections
- Core & Common 사용하는 의존성 프로젝트는 커넥션 풀을 모두 할당받는다.
- java.lang.NoClassDefFoundError
- 특정 모듈이 하위 버전 라이브러리를 참조하는 경우 업그레이드 난해함
- Copy & Paste
- 참조하는 곳이 너무 많아 일단 if .. else 분기 처리 copy & paste
- All Build & Deploy
🚀 Spring, Gradle 멀티 모듈 프로젝트 구성
[Root 프로젝트]
- 📁 src는 필요없으니 삭제하자.
- 🐘 settings.gradle에 하위 모듈을 추가한다.
- include 모듈명
위의 이미지대로라면, 아래와 같이 setting.gradle을 작성하면 된다.
rootProject.name = 'gradle-multi-modules'
include 'grpc-client', 'grpc-server', 'proto'
[하위 모듈]
- gradle 폴더, gradlew 등의 파일이 없다.(있다면 삭제해준다.) ➡️ 빌드는 항상 Root 프로젝트를 기준으로 진행할거라서
- ⚠️ 하위 모듈에 settings.gradle이 있으면 공통 모듈을 import를 해도 인식이 잘 되지 않는 문제를 겪게된다.
🥕 모듈을 import하는 2가지 방법
1. 루트의 build.gradle에서 정의한다.
// membership-service 모듈에서 proto 모듈을 import한다.
project(':membership-service'){
dependencies {
implementation project(':proto')
}
}
2. 하위 모듈에서 다른 모듈을 직접 import
// membership-service의 build.gradle
// membership-service 모듈에서 proto 모듈을 직접 import한다.
implementation project(':proto')
참고 👇
https://www.youtube.com/watch?v=ipDzLJK-7Kc
https://backtony.github.io/spring/2022-06-02-spring-module-1/
https://jojoldu.tistory.com/123
반응형
'Architecture' 카테고리의 다른 글
백엔드 아키텍처 (0) | 2023.04.22 |
---|