MSA를 접하기 시작하면서 드는 생각은 하나의 Micro Service는 어떻게 정의 되어야 하는가? 에대한 의문이 생겼다. 차봇의 서비스 영역이라고 한다면 신차, 중고차, 보험, 금융 이라는 서비스로 묶을 수 있지 않을까 라고 막연하게 생각했고 다른 개발자들은 이걸 어떻게 나누는지 궁금해 찾아보기 시작했다. 그러다가 Microsoft에 있는 설명서 메뉴에 MSA와 DDD를통한 MSA설계에대한 설명이 아주 자세하게 적힌것을 찾았고 왜 DDD를 알아야하는지 설명이 나와있었다.
마이크로 서비스의 가장 큰 해결 과제 중 하나는 개별 서비스의 경계를 정의하는 것입니다. 일반적인 규칙은 서비스가 "한 가지"를 수행해야 하지만 — 해당 규칙을 실행하는 데는 신중한 계획이 필요합니다. "올바른" 설계를 만들어내는 기계적 프로세스는 없습니다. 비즈니스 도메인, 요구 사항 및 목표에 대한 숙고가 필요합니다. 그렇지 않으면 서비스 간의 숨겨진 종속성, 밀접한 결합 또는 불완전하게 설계된 인터페이스 등, 바람직하지 않은 특징을 나타내는 체계적이지 못한 설계로 끝날 수 있습니다. 이 문서에서는 마이크로 서비스를 설계 하는 도메인 기반 접근 방식을 보여 줍니다.
전통적인 개발 방법은 요구사항을 분석한 뒤 데이터 베이스 모델링을 통해서 개발이 되다 보니 빈약한 도메인 모델이 나타나게 되었고 거대한 서비스 레이어가 탄생 그리고 유비쿼터스 랭귀지를 만족하지 못해서 협업에 어려움이 오는 현상이 나타났다.
소프트웨어의 복잡성은 도메인에서 기인하고, 그러한 복잡성을 어떻게 다루느냐가 프로젝트의 성패를 좌우한고, 도메인 주도 설계(DDD)는 복잡한 요건을 지닌 소프트웨어를 개발하는 접근법의 하나라고 한다.
DDD에서는 도메인을 가장 잘 아는 사람(도메인 전문가)과 어떻게 협업 할 것인지가 가장 중요하다.
[그림 2. ]
[그림2. ]에서 보이는 것처럼 개발자는 도메인에 대해서 잘 모를 수 있다. 여기서 도메인을 모델로 추상화를 잘 시키지 못하면 소프웨어 개발과 모델링의 불일치가 발생하게 된다.
이러한 간극을 줄이기 위해 DDD가 나온것이고 도메인에 대해 잘 알고있는 도메인 전문가와 협업을 통해서 공통적으로 의미를 이해할 수 있도록 정의하는 언어를 유비쿼터스 랭귀지 (보편적 언어)라고 한다.