애플리케이션을 기능에 따라 여러 서비스로 분해하는 것이 마이크로서비스의 가장 중요한 과제. 그렇다면 어떻게 분리할까?
계층형 아키텍처 vs 육각형 아키텍처
계층형은 보통 비즈니스 로직을 구현할 때, 리포지토리 인터페이스 (데이터시스템 접근 인터페이스)를 정의하고, 영속화 계층은 리포지토리 인터페이스 DAO를 구현하고, 이후 비즈니스 로직을 영속화 계층에 따라 구현한다. 이렇게 구현할 경우, 영속화 계층에 비즈니스 로직이 의존하게 되버리고, 이는 하위 계층에만 의존하게 하는 계층형 아키텍처의 취지와는 반대가 되어버린다.
육각형 아키텍처의 경우, 논리 뷰를 비즈니스 로직 중심으로 구성시킨다.
제각기 특정한 API나 UI가 구현된 인바운드 어댑터가 비즈니스 로직을 호출하고, 비즈니스 로직은 다양한 외부 시스템을 호출하는 아웃바운드 어댑터를 호출하는 구조이다. 외부 시스템과의 명확한 분리가 있으므로, 육각형 아키텍처는 마이크로서비스 아키텍처를 이루는 각 서비스 아키텍처를 기술하는 가장 좋은 방법이다.
마이크로서비스 아키텍처 정의
아키텍처 정의하는 1단계는 애플리케이션 요건을 핵심 요청으로 추출
2단계는 어떻게 여러 서비스로 분해할지 결정
3단계는 서비스별로 API를 정의
시스템 작업 선별 (1단계)
1. 시스템 작업을 기술하기 위해 필요한 보케블러리를 제공하는 핵심 클래스로 구성된 고수준의 도메인 모델을 생성.
= 사진의 예에서 소비자와 음식점, 배달과 같은 클래스를 뽑아냄. 분석을 지속적으로 반복.
2. 시스템 작업 식별 후 그 동작을 도메인 모델 관점에서 기술.
= createOrder(), acceptOrder()와 같은 동작 뽑아냄
비즈니스 능력 패턴별 분해 (2단계)
- 비즈니스 능력에 따라 서비스 분리
한 조직의 비즈니스 능력은 조직의 목표, 구조, 비즈니스 프로세스를 분석하여 식별한다. 사실 기술보다 비즈니스 위주라는 점만 제외하면 일종의 서비스로 볼 수도 있다. (비즈니스 능력이 곧 서비스)
비즈니스 능력 식별 후, 능력에 따라 또는 연관된 능력 그룹에 따라 서비스 정의
하위 도메인 패턴별 분해
DDD는 도메인을 구성하는 각 하위 도메인(애플리케이션의 문제 공간(problem space)을 가리키는 DDD 용어)마다 도메인 모델을 따로 정의. 하위 도메인은 비즈니스 능력과 같은 방법(비즈니스를 분석하고 상이한 전문 영역을 식별)으로 식별하므로 십중팔구 비즈니스 능력과 유사한 하위 도메인이 도출.
DDD 간략 설명: https://happycloud-lee.tistory.com/94
마이크로서비스 아키텍처와 DDD 매우 유사
분해 지침
SOLID 원칙에 따라 객체 분해해야함
서비스 분해의 장애물
- 네트워크 지연 : 배치API나 언어수준의 메서드로 대체
- 동기 통신으로 인한 가용성 저하 : 비동기 메시징
- 여러 서비스에 걸쳐 데이터 일관성 유지 : 사가 패턴
- 데이터의 일관된 뷰 확보 : 잘 쪼개면 사실상 문제 없음
- 분해를 저해하는 만능 클래스 : DDD의 Aggregate 개념을 통해 분해
서비스 API 정의 (3단계)
시스템 작업과 서비스 후보를 목록화했으니 다음은 각 서비스별 API(작업과 이벤트)를 정의할 차례. 서비스 API 작업은 외부 클라이언트 또는 타 서비스가 호출하는 시스템 작업과 서비스 간 협동을 지원하기 위해 타 서비스 호출 전용으로 만든 작업, 둘 중 하나.
서비스 API를 정의하는 단계
1. 시스템 작업을 서비스로 배정
2. 서비스 간 협동 지원에 필요한 API 확정
"마이크로서비스 패턴" 중에서
크리스 리처드슨
논의할 부분 : DDD의 Aggregate 개념을 통해 분해 => DB의 테이블을 나누자는거? 아니면 객체로만 쪼개고, 테이블은 그대로 두자는거? : 보통 테이블도 분리
매번 사용되는 공통로직,예를 들어 거리 계산이나... 사진 첨부 이런것들... 공통으로 뺀다고 했는데, 공통로직은 마이크로서비스에서 어떻게 처리함? gradle repository에 등록해서 처리? : repository에 공통로직을 넣음
DDD를 적용한 서비스에서, 마이크로서비스로 넘어갈때
이벤트를 전달하는 방식? => 근데 이거 DDD만 적용했을때는 : REST API Call
