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

컨퍼런스13 Oct 2022

“WHY” 멀티 모듈 프로젝트 구조가 중요할까요?

아키텍쳐
- 프로젝트 초기에 이루어져야 하는 일련의 설계 결정
- 요소의 구조와 그 관계에 관한 것
아키텍쳐를 멀티 모듈 프로젝트로 바꿔서 볼 수 있음
시스템이 커져갈수록 빌드와 배포 프로세스가 복잡해짐
나중에 변경하기 어려움
멀티 모듈은 리스크를 줄이기 위한 시작
시간이 갈수록 커지는 core, common 모듈의 문제점
- core, common을 사용하는 의존성 프로젝트는 커넥션 풀을 모두 할당받게 됨
- 특정 모듈이 하위 버전 라이브러리를 참고하는 경우 업그레이드가 어려워짐
- 참고하는 곳이 너무 많아 if-else 구문이 늘어감
- 특정 부분을 수정해도 전체를 빌드, 배포해야 함

역할, 책임, 협력 관계가 올바른지 고민 필요
core, common에 있던 데이터 접근 관련 코드를 모듈로 분리 가능
기술 베이스 기반으로 멀티 모듈이 구성될 경우
- 세부 도메인이 다른 종류의 DB를 사용할 경우, 전체를 포함하는 도메인의 위치 결정 어려움
- 유관 부서, 업체 연동, 시스템 관련 모듈이 추가됨
점점 늘어나는 멀티 모듈을 나눈 기준이 필요
core, common 모듈을 삭제하고 정말 필요한지 고민하기
- 비대해지는 core, common의 문제가 중복 코드보다 더 큰 문제라고 판단
Bounded Context
- DDD에서 큰 모델을 서로 다른 bounded context로 구분
- 상호 관계를 명시하여 처리
- 서버 모듈
  - 잦은 변화
  - batch, admin, api
- 데이터 모듈
  - 도메인
  - 데이터 관련
- 인프라 모듈
  - 연동 모듈
  - 버전 업이 있을 경우, 프로젝트에 큰 변화를 주는 모듈
  - 유관 부서 관련
- 클라우드 시스템 모듈
  - 서버 관리를 위한 모듈
  - 컨테이너 환경과 트래픽 제어를 위한 모듈

왜 멀티 모듈 프로젝트 구조가 중요할까?
- 잘못 구성되면 나중에 변경하기 고통스럽다.
- 프로젝트 초기에 이루어져야 하는 일련의 설게 과정이다.
- 개발 생산성에 막대한 영향을 미친다.
무엇을 기준으로 멀티 모듈 프로젝트 구조를 나누어야 할까?
- 경계 안에서 의미를 가질 수 있는 그룹을 정의하는 것이 가장 중요하다. (Bounded context)
- 역할, 책임, 협력 관계가 올바른지 다시 한 번 생각한다.
- 서버, 인프라, 데이터(도메인), 시스템(클라우드)
어떻게 실전 멀티 모듈 프로젝트 구현을 해야할까?
- 프로젝트가 커지고 있다면 다시 경계를 나누고 그 기준으로 소스 저장소를 분리한다
- 인프라 라이브러리에는 데이터 관련 구현을 지양한다.
- 서비스 구현은 각자 역할에 맞게 각각 구현될 수 있으며 공통으로 한 쪽에 구현하지 않는다.
- 시스템 레벨 구현이 실제 서비스 애플리케이션과 밀접하게 연관되지 않도록 격리하거나 전환한다.