요약
- 6장. 사례연구 - 마이크로서비스 도출과 아키텍처 구성 나머지 부분에 대해 이해함
- JHipster를 활용한 아키텍처 구성
- 백엔드 서비스의 프로젝트 구조 리팩터링
- DTO, 매퍼, 카프카, 페인의 위치
- DTO, 매퍼를 사용하는 방식
- 정리
메모
6.5.3 백엔드 서비스의 프로젝트 구조 리팩터링
DTO, 매퍼, 카프카, 페인의 위치
- 기본적으로 JHipster는 DTO(Data Transfer Object), 매퍼, 카프카, 페인 등이 포함된 패키지 구조를 자동으로 생성함.
- 이러한 구성요소들은 외부 서비스와의 통신에 주로 사용되며, JHipster에서는 DTO와 매퍼를 service 패키지에, 카프카를 web.rest 패키지에 위치시킴.
- 그러나 헥사고날 아키텍처를 적용하려면, 이들 구성요소들의 위치가 바뀌어야 함.
- 특히, REST 컨트롤러에서 필요로 하는 DTO와 매퍼는 web.rest 패키지로 이동해야 하며, 카프카나 페인과 같은 아웃바운드 어댑터의 역할을 수행하는 클래스는 별도의 adaptor 패키지에 위치해야 함.
- 이런 패키지 구조의 변경은 헥사고날 아키텍처의 내부와 외부 영역을 명확하게 표현하는데 도움됨.
- 따라서, 초기에 생성된 패키지 구조를 이와 같이 리팩터링하는 것이 권장됨.
DTO, 매퍼를 사용하는 방식
- JHipster가 초기에 DTO와 매퍼를 service 패키지에 두는 이유는, 서비스 구현체가 이들을 사용하기 때문임.
- 예를 들어, Rental Service 클래스가 반환하는 모든 객체가 DTO임.
- 그러나 이 방식을 따르지 않는 것이 바람직하다고 주장함.
- 외부 영역의 데이터는 거친 입자(coarse-grained)이며 타 서비스의 영향을 받을 수 있지만, 내부 영역은 비즈니스 로직을 명확히 다룰 수 있는 고운 입자(fine-grained)의 도메인 모델을 사용하는 것이 좋음.
- 따라서 서비스 구현체는 도메인 모델 객체를 반환하도록 변경하고, 컨트롤러에서는 내부 서비스에서 받아온 도메인 객체를 DTO로 변환하도록 변경함.
- 이러한 변경으로 인해 REST 컨트롤러는 DTO를 매개변수로 갖게 되고, 서비스 인터페이스와 구현체는 도메인 모델을 매개변수로 사용하게 됨.
정리
- 이 장에서는 도서대출 시스템의 사례 연구를 통해 이벤트 스토밍을 수행하였으며, 이를 통해 마이크로서비스 후보를 도출했음.
- 또한, 사례 연구를 위한 외부 아키텍처와 내부 아키텍처를 정의했음.
- 외부 아키텍처에서는 도커 컨테이너를 가상 환경으로 선택하였고, 스프링 부트를 프레임워크로 채택했음.
- 또한, 마이크로서비스를 지원하는 기반 서비스로는 스프링 클라우드의 API 게이트웨이, 레지스트리, 컨피그 서비스를 구성했음.
- 메시지 전송을 위해서는 카프카를 사용하였고, 형상관리를 담당하는 소스 리포지토리로는 깃허브를 선택했음.
- 내부 아키텍처에서는 헥사고날 아키텍처를 반영하여 내부 영역과 외부 영역을 구분하여 프로젝트의 패키지를 구성하였고, 클래스 유형 및 명명 규칙을 정의했음.
- 이러한 환경을 빠르게 자동으로 생성하고 구성하는 도구로는 JHipster를 선택했음.
- JHipster를 통해 빠르게 아키텍처를 구성하고, 3가지 간단한 백엔드 서비스를 생성하여 프런트엔드 서비스에 연계하여 동작하는 것을 확인했음.
댓글