책너두 (도메인 주도 설계로 시작하는 마이크로서비스 개발) 22일차 (~182p)

요약

• 6장. 사례연구 - 마이크로서비스 도출과 아키텍처 구성 나머지 부분에 대해 이해함
  • 이벤트 스토밍을 통한 마이크로서비스 도출
    • 컨텍스트 다이어그램
    • 이벤트 스토밍 결과를 헥사고날 아키텍처로 표현하기
  • 외부 아키텍처 정의
  • 내부 아키텍처 정의
    • 패키지 구조 및 명명 규칙

메모

6.2.3 컨텍스트 다이어그램

• 마지막 단계에서는 컨텍스트 다이어그램을 작성하여 각 컨텍스트와 그들 간의 동기/비동기 호출 관계를 명확히 표현함.
  • 이 다이어그램에서 점선은 비동기 호출을, 실선은 동기 호출을 나타냄.
• 이렇게 식별된 각 컨텍스트들은 마이크로서비스의 후보가 됨.
  • 여기서 '후보'라는 용어를 사용하는 이유는 서비스가 배포와 운영 효율성 등을 고려하여 더 세분화되거나 통합될 수 있기 때문임.
• 즉, 현재의 바운디드 컨텍스트는 초기 마이크로서비스 설계의 기준이 되지만, 이후에 변경될 수 있음을 인지하고 있어야 함.
  • 그렇게 도출된 후보 마이크로서비스를 바탕으로 설계와 개발을 시작하게 됨.

6.2.4 이벤트 스토밍 결과를 헥사고날 아키텍처로 표현하기

• 이벤트 스토밍 결과를 헥사고날 아키텍처로 표현하는 단계임.
  • 이벤트 스토밍 결과물은 상세한 설계를 위한 기반으로 사용되며, 그 결과는 API 설계, 도메인 모델링, 데이터 모델링의 입력물이 됨.
• 이벤트 스토밍의 각 구성요소는 다음과 같이 헥사고날 아키텍처 구성요소로 매핑됨
  • 커맨드는 외부 영역의 인바운드 어댑터인 API 후보가 됨.
  • 이벤트는 외부 영역의 아웃바운드 어댑터로 전송되는 메시지인 이벤트 후보가 됨.
  • 애그리거트는 내부 영역의 도메인 모델인 도메인 모델 후보가 됨.
  • 인터페이스는 외부 영역의 아웃바운드 어댑터로 연결될 대외 인터페이스인 인터페이스 후보가 됨.
  • 정책은 내부 영역의 비즈니스 로직 규현 규칙 및 외부 영역의 아웃바운드 어댑터로 연결될 다른 서비스와의 방향을 결정하는 요소가 됨.
• 이 결과를 기반으로 도메인 모델링을 계속 진행할 수 있으나, 먼저 아키텍처 정의 활동을 진행해야 함.

6.3 외부 아키텍처 정의

• 외부 아키텍처는 다양한 기술 스택으로 구성되어 있음.
  • 백엔드 마이크로서비스
    • 사용자/로그인, 배송, 대출, 도서, 도서 카탈로그, 게시판, 이메일 등으로 구성되었음.
    • 사용자와 로그인은 하나의 마이크로서비스로 통합되었음.
  • 프런트엔드
    • Vue.js를 사용함.
  • API 게이트웨이
    • 로드 밸런싱과 라우팅 역할을 수행하며, 줄(라우팅)과 리본(로드 밸런싱)을 사용함.
  • 통합 서비스
    • 프런트엔드, 사용자/로그인 백엔드 서비스, API 게이트웨이가 통합된 서비스임.
    • API 게이트웨이의 역할도 포함됨.
  • 서비스 저장소
    • MariaDB를 사용하며, 읽기에 최적화된 NoSQL 데이터베이스인 MongoDB는 카탈로그 서비스에 사용됨.
  • 서비스 통신
    • 동기 통신에는 페인을 사용하며, 비동기 통신에는 메시지 큐를 사용함.
  • 메시지 큐
    • 카프카(Kafka)를 사용함.
  • 배포
    • 도커 컨테이너로 쿠버네티스에 배포함.
  • 로그 중앙화
    • ELK 스택을 사용함.
  • 모니터링
    • Kiali로 모니터링 및 트레이싱을 수행함.
  • 형상관리
    • Github로 형상관리를 수행함.
  • 개발 환경 구축
    • JHipster를 사용하여 쉽게 개발 환경을 구축함.

6.4 내부 아키텍처 정의

• 내부 아키텍처는 폴리글랏(polyglot) 즉, 여러가지 기술이나 방식을 혼합하여 사용하는 성질을 강조함.
• 마이크로서비스의 내부 아키텍처는 서비스의 성격에 따라 다르게 구성될 수 있음.
  • 예를 들어, 비교적 단순한 업무인 게시판 서비스는 SQL 매퍼인 마이바티스를 저장 메커니즘으로 사용하며, 트랜잭션 스크립트 패턴이 비즈니스 로직 구현에 적용되었음.
• 반면에, 주요 업무를 담당하는 대출, 도서, 도서 카탈로그 서비스는 도메인 모델 패턴을 사용하여 비즈니스 로직을 구현하고, 저장 메커니즘으로는 OR 매퍼인 스프링 데이터를 사용함.
• 이처럼 서비스의 내부 아키텍처는 서비스의 특성과 요구사항에 따라 달라질 수 있으며, 이를 통해 서비스 각각의 특성에 가장 적합한 기술 및 설계 방식을 선택할 수 있음.
  • 마이바티스로 구현한 서비스에 대한 상세한 내용은 다루지 않을 예정임.

6.4.1 패키지 구조 및 명명 규칙

• 이 섹션에서는 도메인 모델 중심의 마이크로서비스 내부 구조를 설명하며, 이 구조는 헥사고날 아키텍처 개념을 따르고 있음.
  • 패키지 구조는 내부 영역을 담당하는 패키지와 외부 영역 처리를 담당하는 패키지로 분리되어 있음.
• 내부 영역에는 비즈니스 로직을 표현할 도메인 모델, 서비스 인터페이스, 서비스 구현체, 리포지토리가 존재함.
  • 이와 반대로 외부 영역에는 API를 제공하고 저장소 및 다른 서비스와 연계할 웹 REST 컨트롤러, 어댑터, DTO가 구성되어 있음.
• 명명 규칙에 대해 설명하는 부분에서는 패키지의 이름은 각각 domain, service, repository, web.rest, adaptor, dto로 지정하고, 도메인 클래스인 경우 도메인 개념을 명확히 표현할 수 있는 명사형으로 지정하며, 나머지 인터페이스나 클래스의 경우에는 클래스 역할 유형에 따른 접미사를 적용하는 방법을 권장함.
• 도메인 모델 중심의 마이크로서비스 구조와 차이점은 도메인 패키지 내에 도메인 모델이 존재하지 않으며, OR 매퍼 대신 SQL 매퍼를 사용하므로 SQL 문을 작성할 XML 파일이 추가된다는 것임.