5. 마이크로서비스 설계

모듈화의 근본적 가치는 각 모듈을 기능적으로 응집성 높게 만들고 기능이 다른 타 모듈 간의 의존도를 낮추는 것이다. 

 

마이크로서비스를 도출하는 방법

시스템의 어떤 비즈니스 기능들을 묶어서 독립적인 마이크로서비스로 도출할 것인가를 결정하는 것이 매우 중요하다. 

 

비즈니스 능력에 근거한 도출

마이크로서비스를 식별하는 가장 쉬운 방법은 경험적인 원칙을 적용하는 것이다. 

이러한 방식은 전체적인 대략의 비즈니스를 이해할 때는 유용하지만 서비스 간의 관계를 파악하거나 서비스의 구체 기능과 연관된 서비스가 관리할 독립적인 데이터를 식별하기에는 미흡하다. 이를 보완할 대책이 필요하다. 

 

DDD의 바운디드 컨텍스트 기반 도출

비즈니스 능력에 따른 서비스 도출 한계를 극복하기 위해 DDD의 전략적 설계를 적용할 수 있다. 비즈니스를 처리하는 기능과 그 기능에 영향을 받는 데이터가 분리되는 경향이 있다. 

그렇지만 DDD에서는 이처럼 데이터를 기능과 분리해서 식별하지 않고 문제 영역인 하위 도메인마다 별도의 도메인 모델로 정의한다. 도메인 모델은 각 업무에 특화된 유비쿼터스 언어로 정의되고 그 업무에 특화된 개념으로 구성된다. 

DDD의 전략적 설계 

도메인과 서브도메인

많은 개념들이 하나로 엮인 복잡한 비즈니스 도메인을 논리적으로 구분되는 여러 개의 하위 영역으로 분리해야 한다는 뜻으로, 이렇게 분리된 하위 도메인을 서브도메인이라고 한다. 

서브도메인은 중요도에 따라 핵심 서브도메인, 지원 서브도메인, 일반 서브도메인의 세 가지 유형으로 나뉜다. 

 

먼저 핵심 서브도메인은 다른 경쟁자와 차별화를 만들 비즈니스 영역이기 때문에 기업의 프로젝트 목록에서 높은 우선순위를 갖는 영역이자 소프트웨어 개발에서 전략적으로 가장 큰 투자가 필요한 영역을 말한다. 

두 번재로 지원 서브도메인은 비즈니스에 필수적이지만 핵심은 아닌 부분으로 볼 수 있다. 그러나 핵심 도메인을 성공시키기 위해서는 반드시 필요한 영역으로, 핵심 서브 도메인 다음으로 중요한 영역이다. 

마지막으로 일반 서브도메인은 비즈니스적으로 특화된 부분은 아니지만 전체 비즈니스 솔루션에는 필요한 부분으로, 기존 제품을 구매해서 대체할 수 있다. 

 

이러한 전략적 설계를 수행하기 위해 반드시 알아야 할 중요한 개념 두 가지가 있다. 

1. 도메인의 주요 개념을 정의하고 도메인 간의 경계를 식별하는 바운디드 컨텍스트다. 

2. 도메인의 모든 구성원이 공통으로 사용하는 유비쿼터스 언어다. 

 

유비쿼터스 언어와 도메인 모델, 바운디드 컨텍스트

언어라는 것이 같은 단어나 용어라 해도 특정한 상황(맥락)에 따라 의미가 다르게 해석될 수 있다는 사실을 알 수 있다. 

DDD에서는 이처럼 특정 도메인에서 해당 도메인에서의 의도를 명확히 반영하고 도메인의 핵심 개념을 잘 전달할 수 있는 언어를 유비쿼터스 언어라고 한다. 유비쿼터스 언어를 정의해서 이해관계자가 모두 공통의 언어를 사용하면 고객, 설계자, 개발자까지 용어에 따른 오해를 없앨 수 있게 된다. 

유비쿼터스 언어는 예전에 데이터 모델링에서 사용했던 표준 단어/용어 사전과는 다른 개념이다. 유비쿼터스 언어는 특정 도메인의 업무 개념을 표현하는 언어다.

도메인 모델은 특정 비즈니스 맥락에서 통용되는 개념들의 관계를 잘 정의한 모형이다. 도메인 모델을 보면 해당 비즈니스를 이해할 수 있어야 한다. 따라서 예전처럼 설계 산출물에 사용했던 용어와 소스코드로 구현하면서 사용하는 용어가 다른 방식을 지양한다.

 

컨텍스트 매핑

하나의 큰 도메인을 여러 개의 바운디드 컨텍스트로 식별하면 비즈니스 수행을 위해 여러 개의 컨텍스트가 연계해야 하는 경우가 발생한다. 이러한 컨텍스트 간의 의존 관계를 DDD에서는 컨텍스트 매핑이라 하고, 연관관계에 있는 두 컨텍스트 사이에 선을 그려서 표시한다. 

이벤트 스토밍을 통한 마이크로서비스 도출

이벤트 스토밍은 모든 이해관계자가 모여 서로가 가지고 있는 각 관점을 논의하며, 그 차이점을 이해하고 공유할 수 있다는점에서 기존 방법론에서 장기간 단절하며 수행했던 요구사항, 프로세스 모델링, 설계를 진행하는 과정을 뛰어넘는 민첩성과 효율성을 보여준다. 또한 쉽고 간편한 도구를 사용해 빠른 시간 내에 지식 공유를 통한 협업을 가속화하고 시각화함으로써 서로간의 학습 및 탐색을 촉진하는 워크숍이라 할 수 있다. 

 

백엔드 모델링

API 설계

API는 백엔드 서비스에 존재하지만 프런트엔드의 요구사항을 충족하도록 정의해야 한다. 

최근의 추세는 HTTP 프로토콜과 JSON 포맷을 사용하는 REST API가 표준처럼 사용되고 있다. 이는 REST API 방식이 대중적인 HTTP 프로토콜과 취급하기 쉬운 JSON 포맷, 간단한 HTTP 메서드 형식 등의 특징 덕분에 쉽고 명확해서 누구나 이해할 수 있기 때문이다.

REST API의 구성요소인 자원, 메서드, 표현 방식을 정리할 수 있다. 

 

REST API 성숙도

API 설계 문서화

애자일 모델링 방식을 추구할 때 가급적이면 불필요한 설계물을 남기는 것은 바람직하지 않다. 산출물의 필요성은 항상 공유와 협업 측면에서 고려하자. API 설계는 프런트엔드 엔지니어와 백엔드 엔지니어의 협업 차원에서 중요하다. 

어떤 형태든 최소한 다음 항목은 포함하도록 한다. 

- 서비스명, API 명, 리소스(URI)

- 요청 매개변수, 요청 샘풀

- 응답 매개변수, 응답 샘플

 

도메인 모델링

마이크로서비스의 내부 구조는 폴리글랏하게 접근할 수 있다. 서비스의 내부 영역의 구조를 도메인 모델 중심으로 만들 수도 잇고 트랜잭션 스크립트 형태로 만들 수도 있다. 

 

단순한 로직인 경우에는 트랜잭션 스크립트 구조로 만들어도 무방하다. 그렇지만 비즈니스가 복잡해질수록 비즈니스 개념들을 잘 구조화할 수 있는 도메인 모델 구조가 효과적이다. 도메인 모델 구조는 복잡함을 다루어 쉽게 표현할 수 있는 구조를 제공하기 때문이다. 

 

DDD의 전술적 설계(도메인 모델링 구성요소)

DDD의 전술적 설계는 앞에서 언급한 것처럼 도메인 모델을 구성하기 위한 패턴들을 설명한다. 

기존 객체 모델링 방식은 자유도가 높아 문제 영역을 파고들수록 여러 층의 복잡한 계층 구조를 만들게 될 가능성이 높다. 그래서 이를 정리하기 위해 객체들의 역할에 따른 유형을 정의하고, 이러한 규칙에 따라 모델링하면 단순하고 이해하기가 수월해지는데, 이러한 설계 기법을 DDD의 전술적 설계에서 제공한다. 이 책에서는 도메인 모델을 구성하는 객체 구성 요소를 중심으로 살펴본다.