도메인 주도 설계로 시작하는 마이크로서비스 개발 5-1

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

5.1.1 비지니스 능력에 근거한 도출

비지니스 능력은 비지니스 가치를 생산하기 위해 하는 일입니다. (조직의 업무)

각 도메인에는 일하는 방식, 조직, 부서 체계가 정의되어 있습니다.

이처럼 비지니스 부서가 가진 역활, 처리 능력을 바탕으로 엄부를 분리하고 식별하여 마이크로 서비스를 도출하는 것이 비지니스 능력에 근거한 도출 방식입니다.

하지만 이러한 방식은 비지니스를 이해할 때는 유용하지만, 서비스 간의 관계를 파악하거나 연관된 서비스과 관리할 독립적인 데이터를 식별하기에는 미흡합니다.

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

마이크로서비스는 각 저장소를 독립적으로 보유하고, 각 데이터는 다른 서비스에서 직접 참조해서는 안된다는 특징을 가지고 있습니다.

따라서 마이크로서비스를 도출할 때 서비스가 소유권을 가진 데이터를 독립적으로 식별하는 것이 중요합니다.

즉, 서비스가 보유한 기능에 의해 캡슐화된 데이터를 파악해야 합니다.

도메인주도개발(이하 DDD)에서는 데이터를 문제 영역인 하위 도메인마다 별도의 도메인 모델로 정의합니다.

도메인 모델은 각 업무에 특화된 유비쿼터스 언어로, 그 업무에 특화된 개념으로 구성됩니다.

5.2 DDD에서의 설계

마이크로서비스 아키텍쳐의 장점인 독립적 개선과 배포, 장애 격리, 장애 발생시 빠른 재실행을 가능하게 하기 위해서는 마이크로서비스를 응집성 있게 식별하는 것이 중요합니다.

DDD에서는 비즈니스 응집성이 있는 컨텍스트를 바운디드 컨텍스트라고 합니다.

이 단위를 통해 마이크로서비스를 식별하고 식별된 마이크로서비스의 내부 구조를 정의합니다.

5.3 DDD의 전략적 설계

5.3.1 도메인과 서브도메인

DDD에서는 하나의 큰 도메인을 논리적으로 구분되는 개념으로 나누어 하위 영역으로 분리합니다. 이를 서브도메인이라고 합니다.

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

• 핵심 서브도메인: 프로젝트에서 가장 높은 우선순위를 가지는 영역, 개발시 전략적으로 가장 큰 투자가 필요한 영역.

• 지원 서브도메인: 비지니스에 필수적이지만 핵심은 아닌 부분. 하지만 핵심 도메인을 위해서 반드시 필요한 영역.

• 일반 서브도메인: 비즈니스적으로 특화된 부분은 아니지만 전체 비즈니스 솔루션에는 필요한 부분.

책의 사례를 보자면 아마존의 쇼핑몰에서는 상품 추천 영역을 핵심 서브도메인으로, 쿠팡은 로켓배송을 핵심 서브도메인으로 두었을 가능성이 큽니다.

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

위와 같은 도메인을 나누고 마이크로서비스를 도출하는 전략적 설계를 수행하기 위해 반드시 알아야 할 중요한 개념이 유비쿼터스 언어와 바운디드 컨텍스트 입니다.

일반적으로 현업 담당자가 사용하는 언어와 개발자가 사용하는 기술 언어가 다른 경우가 많습니다. 따라서 서로 용어로부터 생기는 오해를 해결하기 위해 문서화(용어사전)하여 관리하는 과정이 필요합니다.

DDD에서는 해당 도메인에서의 의도를 명확히 반영하고 도메인 핵심을 잘 전달할 수 있는 용어를 유비쿼터스 언어라고 합니다.

유비쿼터스 언어를 정의 함으로써 이해관계자가 공통의 언어를 사용하면 용어에 따른 오해를 없애고 더 나은 소통이 가능해집니다.

유비쿼터스 언어는 세부 도메인에 특정 업무와 관련된 사람들 간의 자율적으로 정의되고 통용되어야 합니다.

유비쿼터스 언어로 잘 정의된 도메인 개념들은 서로 관계를 가집니다. 이 관계들을 잘 정의한 모형이 도메인 모델입니다.

이렇게 구성된 도메인 모델들의 경계가 바운디드 컨텍스트입니다.

도메인 모델은 관련 업무를 수행하는 모든 이해관계자들이 업무를 이해하는 기본 모형입니다. 따라서 실제 설계물과 소스코드의 용어가 상이하면 안되며, 유비쿼터스 언어가 실제 코드에서 살아 숨 쉬어야 합니다.

이렇게 함으로써 새로운 이해관계자가 오더라도 기존의 비지니스를 이해하고 소통하는데 용이해집니다.

5.3.3 컨텍스트 매핑

바운디드 컨텍스트를 식별할 때 내부적으로는 응집성이 높고 다른 컨텍스트와는 의존관계가 낮아야 한다는 원칙을 잊지 말아야 합니다.

하지만 그렇다고 해서 각 컨텍스트 간에 아무 관계가 없다는 것은 아닙니다.

큰 도메인 안에 위치한 여러 컨텍스트는 비지니스 로직 수행을 위해 서로 연계해야 하는 경우가 많습니다. 이러한 컨텍스트 간의 의존 관계를 DDD에서는 컨텍스트 매핑이라고 합니다.

주요 컨텍스트 매핑 관계

1. 공유 커널

공유 커널은 컨텍스트 사이에 공통적인 모델을 공유하는 관계입니다.

보통 공통 라이브러리 등이 여기에 해당하며, 공유하는 모델의 코드 빌드를 관리하고 테스트하는 것은 한 팀이 맡아서 수행해야 합니다.

2. 소비자와 공급자

공급하는 컨텍스트는 상류(Upstream)로, 소비하는 컨텍스트는 하류(Downstream)으로 표현합니다.

여기서 데이터의 흐름은 상류에서 하류로 흐릅니다.

3. 준수자

소비자와 공급자와 유사하지만 상류 팀이 하류 팀의 요구를 지원하지 않거나 못하는 경우 사용합니다.

4. 충돌 방지 계층

하류팀의 고유 모델을 지키기 위한 번역 계층을 만드는 것을 의미합니다.

이 계층은 둘 사이의 차이를 번역하여 적용함으로써 하류 모델의 독립성을 유지합니다. 데이터 변환 메커니즘을 구현한 것이라 할 수 있습니다.

주로 새로운 시스템을 레거시 시스템과 통합하기 위해 주로 사용합니다.

5. 공개 호스트 서비스

하류 컨텍스트가 상위 컨텍스트에서 제공하는 기능을 용이하게 사용할 수 있도록 공개되어 있는 서비스를 의미합니다.

보통 공유 API가 여기에 해당됩니다.

6. 발행된 언어

하류 컨텍스트가 상위 컨텍스트가 제공하는 기능을 사용하기 위한 문서화된 정보 교환 언어입니다.

주로 공개 호스트 서비스와 짝을 이뤄서 사용합니다.

큰 도메인을 여러 개의 바운디드 컨텍스트로 식별하고 이들과의 관계를 표현한 그림을 컨텍스트맵이라고 합니다.

본 글은
도메인 주도 설계 시리즈로 작성 됩니다.
도메인 주도 설계로 시작하는 마이크로서비스 개발 5-1
도메인 주도 설계로 시작하는 마이크로서비스 개발 5-2