3장 : 마이크로서비스 어플리케이션 아키텍처

# DB 중심 아키텍처 문제점

DB 중심 아키텍처 : 특정 RDB에 의존한 데이터 모델링을 수행한 다음 이 물리 테이블 모델을 중심에 두고 APP을 구현하기 위한 사고를 하는 방식

- 간단한 처리 로직은 편하나, 업무가 복잡해지면 점점 복잡성을 제어할 수 없음

- DB에 의존하게 되어 스케일 아웃 성능이 떨어짐

 

# 레이어드 아키텍처

프레젠테이션, 비즈니스로직, 데이터 엑세스 3계층으로 구분하는 것이 일반적

## 레이어드 아키텍처 규칙

- 상위 계층이 하위 계층을 호출하는 단방향성 유지

- 바로 밑의 근접 계층만 활용

- 상위 계층이 하위 계층에게 영향 받지 않게 구성

- 하위 계층은 자신을 사용하는 상위 계층을 알지 못하게 구성

- 계층 간의 호출은 인터페이스를 통해 호출(의존성 분리)

현대 APP은 다양한 인터페이스를 필요로 함, 다양한 상호작용과 다양한 저장소 존재 -> 레이어 페턴으로는 지원 빡셈

 

# 헥사고날 아키텍처 

- 고수준의 비즈니스 로직을 표현하는 내부 영역과 인터페이스를 처리를 담당하는 외부 영역으로 나눔

- 내부 영역은 순수한 비즈니스 로직을 표현, 외부 역역과 연계되는 포트를 가지고 있음

- 외부영역은 외부에서 들어오는 요청을 처리하는 인바운드 어댑터와 비즈니스 로직에 의해 호출되어 외부와 연계되는 아웃바운드 어댑처로 구성

 

- 고수준의 내부 영역이 외부의 구체 어댑처에 의존하지 않음

- 인바운드 어댑터 예시 : rest api  컨트롤러, mvc 컨트롤러, 커멘드 컨트롤러, 이벤트 메시지 구독 헨들러

- 아웃바운드 어댑터 예시 : 데이터 엑세스 처리 담당 DAO, 이벤트 메시지 발행 클래스, 외부 서비스 호출 프록시

 

# 클린 아키텍처

- 엔티티 : 핵심 업무 규칙과 데이터의 결합

- 유스케이스 : 특화된 업무규칙을 표현, 엔티티 내부 핵심 업무 규칙을 호출, 시스템에 사용하는 흐름을 담음.

- 세부사항 : 유스페이스를 감싸고 있는 모든 영역 IO, 저장소, 웹 시스템, 서버 , 프레임워크, 통신 프로토콜 등 

 

# MSA 내부 구조

- 내부 영역에서는 맨 안쪽에 도매인이 존재하고, 도메인을 서비스가 감싼다.

- 도메인은 핵심 비즈니스 로직, 서비스는 도메인을 호출해서 업무를 처리

- 서비스 인터페이스는 외부 영역이 내부 영역에 대한 추이 종속성 방지 및 정보 은닉 효과를 가짐

 

## 트랜젝션 스크립트 패턴

도메인은 정보 묶음 역할만, 비즈니스 수행은 서비스에만 있음

- 비슷한 유스케이스 경우 서비스에 중복되는 코드가 생김

- 데이터 중심 아키텍처 혹은 간단한 비즈니스 처리 적합

## 도메인 모델 패턴 

- 도메인 객체가 데이터뿐만 아니라 비즈니스 행위를 가짐. 도메인 객체가 소유한 데이터는 도메인 행위에 의해 은닉

- 도메인 객체는 각 비즈니스 개념 및 행위에 대한 책임 수행, 서비스는 비즈니스 유스케이스를 구현하기 위해 서비스 행위를 도메인 객체에 일부분 위임해서 처리

- 서비스 책임들이 도메인으로 적절히 분산되기 때문에 서비스가 단순해짐

 

## 도메인 주도 설계의 애그리거트 패턴

최상위에 존제하는 루트 엔티티를 중심으로 개념의 집합을 분리한 것

다음과 같은 규칙 부여

1. 애그리거트 루트만 참조

2. 애그리거트 내 상세 클래스를 바로 참조하지 않고 루트를 통해 참조해야, 수정할 때도 마찬가지

3. 애그리거트 간 참조는 객체를 직접 참조하는 대신 기본 키 사용

4. 하나의 트랜젝션으로 하나의 애그리거트만 수정

 

# MSA 외부영역 - 세부사항

- API 퍼블리싱 어댑터 : rest 형식 api 제공, 엔티티를 직접 제공하지 않고, api에 맞는 DTO를 생성해서 엔티티 변환 및 매핑하여 전달이 바람직

- API 프락시 어댑터 : 내부 영역에 정의된 프락시 인터페이스 구현, 소켓이나 soap 프로토콜 등

- 저장소 처리 어댑터 : SQL 혹은 OR 매핑방식 사용

- 도메인 이벤트 발행 어댑터

- 도메인 이벤트 헨들러