실전! 멀티 모듈 프로젝트 구조와 설계

멀티 모듈프로젝트 아키텍처를 사용한다는 것
- 아키텍처는 나중에 변경하기 어려우며, 리스크를 줄이기 위한 시작이다
- 아키텍처는 빌드, 배포 프로세스와 밀접한 연관이 있기 때문

잘못 나눈다면?
- 갈수록 거대해지는 Core, Common
  - 공통 모듈을 모아놓으려다 보니 기하급수적으로 커짐
  - 수정 및 배포 시 전체가 빌드되어야 하다보니 생산성이 매우 떨어짐

core, common 을 삭제하고, core, common 이 진짜 필요할 지 고민
- 일부 중복이 core, common 이 거대해지는 것보다 낫다

문맥으로 경계를 나눈다 (Bounded Context)
- DDD는 큰 모델을 서로 다른 Bounded Context로 나누고 상호 관계를 명시하여 처리합니다.

WHY 멀티 모듈 프로젝트 구조가 중요할까요?
- 잘못 구성되면 나중에 변경하기 고통스럽다.
- 프로젝트 초기에 이루어져야 하는 일련의 설계 과정이다.
- 개발 생산성에 막대한 영향을 미친다.
WHAT 을 기준으로 멀티 모듈 프로젝트 구조를 나뉘어야 할까요?
- 경계 안에서 의미를 갖을 수 있는 그룹을 정의하는(나누는) 것이 가장 중요하다. (Bounded Context)
- 역할, 책임, 협력 관계가 올바른지 다시 한번 생각한다.
- BOOT(Server), INFRA, DATA(Domain), SYSTEM(Cloud)
HOW 실전 멀티 모듈 프로젝트 구현을 해야 될까요?
- 프로젝트가 커지고 있다면 다시 경계를 나누고 그 기준으로 소스 저장소를 분리한다.
- INFRA(외부) 라이브러리에는 DATA 관련 구현을 지향한다. (Anticouruption Layer)
- 서비스 구현은 각자 역할에 맞게 각각 구현될 수 있다. (공통으로 한쪽에 구현하지 않는다.)
- 시스템 레벨 구현이 실제 서비스 애플리케이션과 밀접하게 연결되지 않도록 격리하거나 전환(istio) 한다.

실전! 멀티 모듈 프로젝트 구조와 설계@인프콘 2022 #5