멀티 모듈 프로젝트 구조와 설계(#SpringBoot#Gradle)

 

본 글은 실전! 멀티 모듈 프로젝트 구조와 설계 | 인프콘 2022에서 들은 내용을 바탕으로 작성한 글이다.

현업에서의 멀티모듈 개발 환경에서 필요한 팁들을 기록해놓았다.

 

★Point

- 정말 모든 곳에서 다 필요한가요?(= 정말 CORE, COMMON 한가요?)

점점 난해해진다.

 

1. 지속적으로 늘어나는 멀티모듈's

=> Core와 Common을 대체 시킬 수 있는 방법이 필요함.

* 배포독립성/ 개발독립성 필요함 => Core/Common을 가볍게

경계를 나눠 프로젝트를 구성하기

경계를 나누어 다음과 같이 구성해야한다.

 

예시

(우리는 이렇게 모듈을 나눴어요: 멀티 모듈을 설계하는 또 다른 관점 | 인프콘2023)

2023 공통모듈 관련 예시

 

---

아래는 springboot, gradle 기반 멀티모듈 프로젝트 예시이다.

 

좌(1)에서 우(2) 예시로 발전시켜나간다.

1. 구성을 하면, 복잡도 증가 => 2. 특성에 맞게 프로젝트 분리시, 빌드시간 감소 + 인터페이스 구성하기 용이

 

---

1. 배치 Job이 많은경우 아래와 같이 문제가 발생한다.

2. DB접근을 데이터 모듈쪽에서 이동해서 구현, 

Too many connections을 피하기 위한 해결방식(우)

 

---

 

Service 레이어 구현은 어디에 해야하는가?

: boot단과 data단 쪽 양쪽에 구현 가능하다.(어느 한쪽에만 구현해야된다는 것은 X)

---

요약

Why?: 왜 멀티 모듈 프로젝트 구조가 중요할까요?

• 잘못 구성되면 나중에 변경하기 힘들다.
• 프로젝트 초기에 이루어져야하는 일련의 설계 과정임.
• 개발 생선성 영향 大

 

What? : 무엇을 기준으로 멀티 모듈 프로젝트 구조를 나뉘어야할까요?

• 경계 안에서 의미를 가질수 있는 그룹을 나누는(정의하는) 것이 중요
• 역할/책임/협력 관계가 올바른지
• BOOT(Server), Infra, Data(Domain), System(Cloud) 등 예시자료

 

How? : 어떻게 실전 모듈 프로젝트 구현을 해야할까요?

• 프로젝트가 커지고 있따면 다시 경계를 나누고 그 기준으로 소스 저장소를 분리함.
• Infra(외부) 라이브러리에는 DATA 관련 구현을 지향한다.(Anticoruption Layer)
• 서비스 구현은 각자 역할에 맞게 각각 구현될 수 있다.(공통으로 한쪽에 구현하지 않는다.)
• 시스템 레벨 구현이 실제 서비스 Application과 밀접하게 연관되지 않도록 격리/전환 한다.