개발자의 오르막
지속 가능한 개발을 위한 멀티모듈과 SpringBoot 본문
Keyword
Multimodule , common , 지속가능한 개발 , 확장성 , 결합도 , 응집도
Overview
멀티모듈이라 할 때 가장 먼저 생각나는 키워드는 무엇일까? 바로 스파게티 소스이다. 특히나 자바 개발자로서 의존성 덩어리의 모듈을 바라보았을 때는 그저 기피하고 회피하고 싶은 구성이다.
그러나 애플리케이션마다 여러 레파지토리로 분리하는 것은 너무 많은 번거로움을 만들어낸다. 예를 들어, API 어플리케이션과 ADMIN 어플리케이션이 있다고 하자. 동일하게 사용하는 도메인 로직을 변경할 때 각 레파지토리에서 로직간의 충돌을 고려해야 한다.
특히 JPA 를 사용할 때의 Entity 클래스는 변경 소요가 있을 때마다 모든 레파지토리를 신경써야한다.
물론 처음 개발할 때부터 기능명세를 명확히 하고, 도메인 변경 소요를 최소화하여 개발하면 이 번거로움은 줄어들 것이다. 이 말은 모두에게 익숙하면서 꺼려지는 폭포수 개발 방법론이다. 서비스는 복잡하고, 시시각각 급변하며, 특히나 서비스의 시작점은 무수한 피벗으로 인해 변경소요가 다분하다.
때문에 서비스가 성숙해지면서 각 기능이 견고해지면서 독립적일 수 있을 때까지 하나의 레파지토리에서 개발을 진행하다, 분리에 대한 소요가 비즈니스적인 판단으로 필요할 때, 우리는 그에 맞춰 진행하는 것이 이상적이다.
따라서 우리는 변화를 수용할 수 있는 확장성과 결합도가 낮으며, 응집도가 높은 개발을 할 수 있어야한다.
그렇다면 이 멀티모듈 구성은 어떻게 해야 할까?
Layerd Architecture
우리 어플리케이션의 구조는 아래와 같이 계층별로 이루어진다.
Presentation Layer (표현계층 , Controller)
- 사용자 요청에 대해 해석하고 응답하는 일을 책임지는 계층
- 기능
- Client 로부터 Request 를 받고, Response 를 응답하는 API 정의
- 요청 방식에 따른 파라미터 검증
Application Layer (응용 계층, Service)
- 비즈니스 로직을 정의하고 정상적으로 수행될 수 있도록 도메인 계층과 infrastructure 계층을 연결해주는 역할을 하는 계층
- 실질적인 데이터의 상태 변화 등의 처리는 도메인 계층에서 진행할 수 있도록 위임하는 것이 중요
- 기능
- 트랜잭션의 단위
- DTO 변환
- Entity 조회 및 저장
- 비즈니스 로직에 따른 Parameter 검증
Domain Layer (도메인 계층, Model)
- 비즈니스 규칙, 정보에 대한 실질적인 도메인에 대한 정보를 가지고 있으며, 이 모든 것을 책임지는 계층
Infrastructure Layer (인프라 계층, Repository)
- 외부와의 통신 (DB, 메시징 시스템 등)을 담당하는 계층
- 해당 계층에서 얻어온 정보를 응용 계층 또는 도메인 계층에 전달하는 것이 주 역할이다.
이러한 Layer 계층을 볼 때, 우리는 변경소요를 예측해볼 수 있다.
- Infrastructure 계층은 기술적인 선택으로 인한 변경소요가 있겠구나.
- 추상화를 통해 여러 기술적인 방법을 선택할 수 있도록 고려해보자.
- Domain Layer
- 비즈니스 로직에 대한 변경소요가 있을 때 , (비즈니스적인 판단) 변경소요가 있겠구나.
- 이는 하나의 서비스이기 때문에 어떤 애플리케이션이던지 일관된 비즈니스로직을 제공해야하구나
- Application Layer
- 사용자 요청에 따른 서비스를 호출하는 방식에서 변화가 생기면 변경될 수 있겠구나.
- client 의 하나의 요청으로 우리 서비스에서 어떤 로직들을 처리하는지 한눈에 볼 수 있는 것이 중요하겠다.
- Presentation Layer
- 사용자에게 어떤식으로 보여줄지에 대한 변경이 있으면 변경소요가 있겠구나.
- 각 애플리케이션마다 호출하는 데이터가 달라질 수 있겠군
MultiModule 을 만들고자 할 때의 목표
- 그럼, Domain Layer 는 각 도메인별로 비즈니스로직을 구성하고, 모든 애플리케이션에 일관된 로직을 수행해야 하는 거네? 추후 분리되기 용이하게
- Application Layer 는 애플리케이션을 사용하는 사용자에 따라 도메인 데이터를 선택해서 보여줄 수 있어야하고,
- Infrastructure Layer 는 기술적 선택으로 전환하기 용이하게 만들어야겠다.
만들고자 하는 모듈 구조
- app-service-api
- 프레젠테이션 계층으로서 내부 App API 를 제공한다.
- app-external-api
- 공공데이터 API 와 통신 후 데이터 후처리 작업을 진행한다.
- app-batch
- Batch 작업을 진행한다.
- domain
- 하나의 모듈은 최대 하나의 인프라스트럭처에 대한 책임만 갖는다.
- 도메인 모듈을 조합한 더 큰단위의 도메인 모듈이 있을 수 있다.
- common
- Type, Util 등을 정의한다.
- 가능하면 사용하지 않는다.
다음 시간에는 각 Layer 별 위의 역할에 따른 구성을 진행해보겠다.
Reference
'Toy Project > Tortee' 카테고리의 다른 글
| SpringBoot 에 Firebase Admin Auth SDK 적용하기 (0) | 2022.12.12 |
|---|---|
| Layer Architecture 에 따른 멀티모듈 구성하기 (0) | 2022.11.12 |
| Spring Boot Rest Docs 멀티모듈 프로젝트에 적용 (0) | 2022.10.17 |
