[105호] 실전! 멀티 모듈 프로젝트 구조와 설계
Previous[103호] 코드 리뷰의 또 다른 접근 방법: Pull Requests vs. Stacked ChangesNext[105호] 지금 당장 DevOps를 해야 하는 이유
Last updated
Last updated
💡 김대성 by NAVER
멀티 모듈 프로젝트 구조 만들기 어렵지 않나요? 어렵다는 표현보다는 만들고도 이게 올바르게 적절하게 만들어진 건지 고민되지 않았나요? 멀티 모듈 프로젝트 구조를 만드는 방법은 사실 정해진 규칙이나 디자인 방법이 없습니다. 그렇지만 제가 지금까지 경험했던 6번의 신규 온라인 프로젝트와 18년 된 레거시 프로젝트 구조를 현대화하는 프로젝트를 통해 느낄 수 있었던 것들이 있습니다. 개발자가 모르면 언젠가 후회할 수밖에 없는, 오직 현장에서만 익힐 수 있었던 내용을 아래 세 가지 주제로 이야기해 보려고 합니다.
왜 멀티 모듈 프로젝트 구조가 중요할까요? 멀티 모듈 프로젝트 구조를 나누는 기준은 뭘까요? 실전 멀티 모듈 프로젝트 구조는 어떻게 잡아야 할까요?
개발자라면 누구도 피해 갈 수 없고 경험할 수밖에 없는, 그리고 한 번쯤은 본인의 손으로 구현할 수밖에 없는 평범하지만 나름 비범한 ‘BE 멀티 모듈 프로젝트 구조와 설계’ 방법을 공유해 드리겠습니다.
아키텍처는 프로젝트 초기에 이루어져야 하는 일련의 설계 결정이다
한번 결정된 아키텍처는 변경을 하기 위해서는 생각보다 많은 공수가 든다
그렇기 때문에 초기에 아키텍처 설계는 매우 중요하고 그 중에서도 멀티 모듈은 의존성을 줄여주거나 확장성을 열어줄 수 있는 다양한 이점을 준다
대부분은 무조건 중복 코드를 줄여야 한다는 강박관념에 core, common 모듈로 옮기는 경우가 있다
Core, Common 모듈에는 생각보다 많은 로직이 내제되어 있어 너무 많은 커넥션 풀을 가지게 된다(admin → 회원, core,common → 상품, 회원, 주문) / (batch → 주문, core,common → 상품, 회원, 주문) /
Core, Common 모듈에서 사용하는 라이브러리로 인해 사이드 이펙트가 발생할 수 있다(ex. log4j 보안 이슈)
Core, Common 모듈에서 공통로직만 사용하다보니 사용하는 쪽에서 생각보다 비슷한 로직이 많이 구현된다(ex. 비밀번호 마스킹 처리)
Core, Common 모듈을 사용하는 특정 클래스를 배포할 경우, 한 글자를 수정하려고 해도 전체 빌드가 되어야 한다. → 이는 개발 생산성에 막대한 영향을 끼친다
역할, 책임, 협력 관계가 올바른지 확인해봐야 한다(feat. 객체지향의 오해와 진실)
문제의 근원인 Core, Common을 지운다(trade off)
일부 코드에 대해서는 중복을 허용한다
Core, Common이 잠재적으로 가지고 있는 위험이 오히려 더 크다
역할을 나눌때 DDD 기준으로 Bounded Context로 나누면 좀더 명확하게 나눌수 있다
서버 모듈(잦은변화)
데이터 모듈(도메인 영역)
인프라 모듈(유관부서, 외부 API 연동)
클라우드 모듈(시스템)
레포지토리 분리(특성에 맞게 분리한다) → 이는 빌드 시간이 줄어들고 프로젝트 경계가 명확해진다
서비스 크기가 작다면 레포지토리 내에서 패키지 별로 구분할 수 있겠지만 점차 확장하게 되면 모듈이 늘어나게 되고 그러면 빌드 속도가 느려지게 된다
레포지토리 간(모듈)간의 통신은 인터페이스 스펙도 명확해 진다
too many connection을 해결하기 위해 디비 접근을 data 모듈로 이동하였다
모듈을 의미있게 나누게되면 자신의 역할과 책임만 구현하면 된다
경험한 내용을 공유해보자면…
서비스 로직은 어느 한 곳에만 구현하는게 아니다(역할에 맞게 구현 로직을 구분해서 각자 구현해야할 필요도 있다)
그렇기 때문에 어느정도 상호간의 규칙이 필요하다
명심해야 할 부분은 절대 타 모듈의 모델을 그대로 전달하면 안된다(의존성 이슈)
어느 회사나 부서가 나뉘어지고 합쳐지기도 한다
그렇기에 언제든 조직 방향성에 맞게 합쳐지거나 나눠질수 있어야 한다
그런 변화에 유연하게 대응할 수 있는 아키텍처를 설계하기에 멀티 모듈은 큰 장점이 있다
