❒ Description
이전 직장에서 진행했던 wewoot은 Monolithic 프로젝트였다. 물론 각 클래스 파일들은 각자의 역할에 맞는
디렉토리에 위치해 있었다. 하지만 여기서 문제는 admin이 였는데, Admin-api와 Was-api가 섞여 있는 구조였다.
이런 구조에서 admin을 배포하든, was를 배포하든 결국 프로젝트 내 모든 파일들을 대상으로 빌드가 이루어졌다.
위의 문제를 해결하기 위해 더 나은 설계가 있는지 찾아보다가 멀티 모듈이라는 것에 알게되었고, 해당 구조를
wewoot에 적용을 하면 보다 나은 프로젝트 구조가 잡힐 것 같다는 생각이 들었다.
이번 기회에 궁금증들을 해결하고 아래의 내용들을 학습해 볼 예정이다.
‣ 멀티모듈과 디렉토리의 차이는?
‣ 멀티 모듈은 필수인가?
‣ 구분 기준을 어떻게 설정해야 할까?
‣ 멀티 모듈은 설정 밥법은?
❒ 멀티 모듈 vs 디렉토리
1. 디렉토리
디텍토리는 파일 시스템에서 파일과 다른 디렉토리를 조직화하는데 사용된다.
| Organization | 파일, 리소스, 설정파일 등을 그룹화하여 프로젝트를 구조화한다. |
| Conflict prevention | 패키지 구조와 네임스페이스를 통해 충동을 방지한다. |
| Management | 큰 프로젝트에서 파일을 쉽게 찾고 관리할 수 있다. |
2. 모듈
모듈은 더 높은 수준의 추상화로, 특정 기능이나 관련 기능 집합을 캡슐화한다.
| Reusability | 독립적으로 개발되고, 다른 프로젝트나 애플리케이션에서 재사용 가능 |
| Independece | 종속성, 설정, 테스트 등을 독립적으로 가질 수 있어, 다른 모듀관의 의존성을 최소화 |
| Deployment | 독립적으로 빌드되고 배포될 수 있다. |
| Encapsulation | 내부 구현을 숨기고 외부에 인터페이스만 제공하여 코드의 복잡성을 낮춤. |
차이점을 요약해보면, 모듈은 기능적 단위 로 더 높은 수준의 추상화를 할 수 있으며 독립적으로 빌드되고 배포 될 수
있다. 결국 프로젝트의 목적성에 맞게 어떠한 구조를 가져갈지 잘 따져보고 프로젝트 관리하는 점이 필요로 해보인다.
❒ 멀티 모듈은 필수인가?
위 단락에서 공부한 내용을 토대로 생각하면 꼭 필수는 아니라고 생각한다. 다만, 아래의 성격을 가진 프로젝트의
경우 멀티 모듈 구조를 사용하면 보다 유연하고 확장성있게 프로젝트를 관리할 수 있을 것 같다.
- MSA 아키텍쳐를 적용한 대규모 프로젝트
- 재사용성이 높은 프로젝트
- 디렉토리 구조화로는 한계를 느낄 때
❒ 구분하는 기준은 어떻게 될까?
1. 기존의 DDD 방식
기존의 DDD 방식으로 모듈화를 하면 아래의 문제점 생길 것으로 생각된다.
- 에티티 추가에 따른 모듈 증가
- 모듈 증가로 인한 설정 파일 관리의 번거로움
- 모듈간 의존성이 커질 수 있음
2. 기능적 단위의 추상화
모듈은 기능적 단위의 추상화라고 했었다. 현재 프로젝트를 기능적 단위로 구분하면 아래와 같다.
- Internal APIs (client API + admin API + cron API)
- External APIs (카카오 API, 결제 시스템 API)
- Common Utils
- Domain files
Interal API의 경우 시간이 지남에 따라 그 크기가 엄청 커질 것 같다(일명 Fat Jar).
그래서 Internal API를 사용자가 집접 호출하는 API와 아닌 API로 나눠봤다.
`Client` + `Admin & Cron` 이렇게 묶어보는 것도 괜찮은 접근일 것 같다.
| Internal-client-API | 사용자가 직접 호출하는 API 및 설정이 포함된 모듈 |
| Internal-operation-API | admin + aws cron에서 호출하는 API 및 각 설정이 포함된 모듈 |
| external-api | 외부 연동 API 및 설정이 포함된 모듈 |
| global-utils | 모든 모듈이 공통적으로 사용하는 로직이 포함된 모듈 |
| core-domain | 도메인에 관련된 모든 파일이 포함된 모듈 |
멀티 모듈 구조 관련해서 좋은 블로그 글