도메인 분석을 사용하여 마이크로 서비스 모델링

  • 아티클

마이크로 서비스의 가장 큰 해결 과제 중 하나는 개별 서비스의 경계를 정의하는 것입니다. 일반적인 규칙은 서비스가 “한 가지”를 수행해야 하지만 해당 규칙을 실행하는 데는 신중한 계획이 필요합니다. "올바른" 설계를 만들어내는 기계적 프로세스는 없습니다. 비즈니스 도메인, 요구 사항 및 목표에 대한 숙고가 필요합니다. 그렇지 않으면 서비스 간의 숨겨진 종속성, 밀접한 결합 또는 불완전하게 설계된 인터페이스 등, 바람직하지 않은 특징을 나타내는 체계적이지 못한 설계로 끝날 수 있습니다. 이 문서에서는 마이크로 서비스 설계에 대한 도메인 기반 접근 방식을 보여 줍니다.

이 문서에서는 드론 배달 서비스를 실행 예제로 사용합니다. 시나리오 및 해당 참조 구현에 대한 자세한 내용은 여기에서 읽을 수 있습니다.

소개

마이크로 서비스는 데이터 액세스나 메시징 등, 수평적 레이어가 아닌 비즈니스 기능을 중심으로 설계되어야 합니다. 또한 느슨한 결합과 유효한 응집력이 있어야 합니다. 다른 서비스를 동시에 업데이트하지 않고도 한 서비스를 변경할 수 있다면 마이크로 서비스가 느슨하게 결합된 것입니다. 사용자 계정 관리, 전달 기록 추적 등과 같이 잘 정의된 단일 용도가 있으면 응집력이 있는 마이크로 서비스입니다. 서비스는 도메인 지식을 캡슐화하고 해당 지식을 클라이언트로부터 추상화해야 합니다. 예를 들어 클라이언트는 상세한 예약 알고리즘이나 드론 선단 관리 방법을 모르고도 드론을 예약할 수 있어야 합니다.

DDD(도메인 기반 설계)는 잘 설계된 마이크로 서비스 집합을 가장 잘 활용할 수 있는 프레임워크를 제공합니다. DDD에는 전략과 전술 등, 개별적인 두 단계가 있습니다. 전략적 DDD에서는 대규모 시스템 구조를 정의합니다. 전략적 DDD는 아키텍처가 비즈니스 기능에 계속 주력하게 하는 데 도움이 됩니다. 전술적 DDD는 도메인 모델을 만드는 데 사용할 수 있는 디자인 패턴 집합을 제공합니다. 이러한 패턴에는 엔터티, 집계 및 도메인 서비스가 포함됩니다. 이러한 전술적 패턴은 느슨하게 결합된 응집력 있는 마이크로 서비스를 설계하는 데 도움이 됩니다.

DDD(도메인 기반 디자인) 프로세스의 다이어그램

이 문서와 다음 문서에서는 다음 단계를 통해 이를 드론 배달 애플리케이션에 적용해 보겠습니다.

  1. 애플리케이션의 기능 요구 사항을 이해하기 위한 비즈니스 도메인 분석부터 시작합니다. 이 단계의 결과는 비공식적인 도메인 설명으로, 보다 공식적인 도메인 모델 세트로 구체화할 수 있습니다.

  2. 다음으로 도메인의 경계가 있는 컨텍스트를 정의합니다. 각각의 제한된 컨텍스트에는 큰 애플리케이션의 특정 하위 도메인을 나타내는 도메인 모델이 포함됩니다.

  3. 제한된 컨텍스트 내에서 전술적 DDD 패턴을 적용하여 엔터티, 집계 및 도메인 서비스를 정의합니다.

  4. 이전 단계의 결과를 사용하여 애플리케이션에서 마이크로 서비스를 식별합니다.

이 문서에서는 주로 DDD와 관련된 첫 세 단계를 다룹니다. 다음 문서에서는 마이크로 서비스를 알아봅니다. 그러나 DDD는 반복적이고 계속되는 프로세스라는 점을 기억해야 합니다. 서비스 경계는 붙박이가 아닙니다. 애플리케이션 진화에 따라 서비스를 더 작은 규모의 여러 서비스로 분할할 수 있습니다.

참고

이 문서에는 완전하고 포괄적인 도메인 분석이 나오지 않습니다. 요점을 설명하기 위해 일부러 간략한 예를 사용합니다. DDD에 대한 자세한 배경 정보는 처음 이 용어를 사용한 책인 Eric Evans의 Domain-Driven Design을 추천합니다. Vaughn Vernon의 Implementing Domain-Driven Design도 참조하는 것이 좋습니다.

시나리오: 드론 배달

Fabrikam, Inc.라는 회사가 드론 배달 서비스를 시작합니다. 이 회사는 다수의 드론 항공기를 관리합니다. 기업은 서비스에 등록하고 사용자는 배달을 위해 드론이 상품을 픽업하도록 요청할 수 있습니다. 사용자가 픽업을 예약하면 백 엔드 시스템이 드론을 할당하고 사용자에게 예상 배달 시간을 알립니다. 배달이 진행되는 동안 지속적으로 업데이트되는 ETA를 통해 고객은 드론의 위치를 추적할 수 있습니다.

이 시나리오에는 상당히 복잡한 도메인이 포함됩니다. 비즈니스 우려 사항으로는 드론 예약, 패키지 추적, 사용자 계정 관리, 기록 데이터 저장 및 분석 등이 있습니다. 또한 Fabrikam은 빠르게 시장에 진입 및 반복하며 새로운 기능을 추가하고자 합니다. 애플리케이션은 SLO(서비스 수준 목표)가 높은 클라우드 규모에서 작동해야 합니다. 또한 시스템의 각 부분에서 데이터 스토리지 및 쿼리에 대한 요구 사항이 완전히 달라야 합니다. 이러한 모든 사항을 고려한 끝에 Fabrikam은 드론 배달 애플리케이션에 마이크로 서비스 아키텍처를 사용하기로 선택합니다.

도메인 분석

DDD 방식을 사용하면 모든 서비스가 기능적인 비즈니스 요구 사항에 자연스럽게 부합하는 마이크로 서비스를 설계할 수 있습니다. 조직의 경계나 기술 선택에 따라 설계가 끌려가게 되는 상황을 방지하는 데도 도움이 됩니다.

코드를 작성하기 전에, 만드는 시스템에 대한 개요가 필요합니다. DDD는 비즈니스 도메인을 모델링하고 도메인 모델을 만드는 데서 출발합니다. 도메인 모델은 비즈니스 도메인의 추상적 모델입니다. 도메인 지식을 거르고 정리하며 개발자와 도메인 전문가를 위한 공통 언어를 제공합니다.

먼저 모든 비즈니스 기능과 그 연결을 매핑합니다. 이는 도메인 전문가, 소프트웨어 설계자 및 기타 이해 관계자가 참여하는 공동 작업일 수 있습니다. 특정 형식이 필요하지 않습니다. 다이어그램을 스케치하거나 화이트보드에 그릴 수 있습니다.

다이어그램을 채울 때는 분리된 하위 도메인을 식별하는 것부터 시작할 수 있습니다. 어떤 기능이 밀접하게 관련되는가? 비즈니스에 핵심이 되는 기능은 무엇이며 어떤 기능이 보조 서비스를 제공하나요? 종속성 그래프란? 이 초기 단계에서는 기술이나 구현 세부 정보는 고려하지 않습니다. 즉 애플리케이션이 CRM, 결제 처리 또는 청구 시스템 등, 외부 시스템과 통합되어야 하는 지점을 확인해야 합니다.

예: 드론 배달 애플리케이션

최초 도메인 분석 후에는 Fabrikam 팀이 드론 배달 도메인을 묘사하는 개괄적인 스케치를 갖게 됩니다.

드론 배달 도메인의 다이어그램

  • 배송은 이 비즈니스의 핵심이므로 다이어그램의 중앙에 있습니다. 다이어그램의 다른 모든 항목은 이 기능을 구현하기 위해 존재합니다.
  • 드론 관리도 이 비즈니스에서 핵심입니다. 드론 관리와 밀접한 관련이 있는 기능에는 드론 복구와, 드론 서비스 및 유지 관리가 필요한 시점을 예측하는 예측 분석이 포함됩니다.
  • ETA 분석은 수거 및 배달에 대한 추정 시간을 제공합니다.
  • 타사 운송은 드론만으로는 패키지를 배송할 수 없는 경우 대체 운송 수단을 예약하는 애플리케이션을 구현합니다.
  • 드론 공유는 핵심 비즈니스의 가능한 확장입니다. 회사에서 특정 시간대에 용량이 남아 유휴 상태가 되는 드론을 대여할 수 있습니다. 이 기능은 초기 릴리스에 없습니다.
  • 비디오 감시는 회사가 나중에 확장할 수 있는 다른 영역입니다.
  • 사용자 계정, 청구 및 콜 센터는 핵심 비즈니스를 지원하는 하위 도메인입니다.

프로세스의 이 시점에서는 구현이나 기술에 대한 어떠한 결정도 이루어지지 않았습니다. 하위 시스템 중 일부에는 외부 소프트웨어 시스템이나 타사 서비스가 관련될 수 있습니다. 그렇다 하더라도 애플리케이션은 이러한 시스템 및 서비스와 상호 작용해야 하므로 도메인 모델에 이를 포함시키는 것이 중요합니다.

참고

애플리케이션이 외부 시스템을 사용할 경우 외부 시스템의 데이터 스키마나 API가 애플리케이션에 유입되어 구조적 설계를 저해할 위험이 있습니다. 특히 최신 모범 사례를 따르지 않아 구형 데이터 스키마나 통용되지 않는 API를 사용하는 기존 시스템인 경우가 그렇습니다. 이 경우에는 해당 외부 시스템과 애플리케이션 간의 경계를 잘 정의하는 것이 중요합니다. 이러한 용도로 Strangler Fg 패턴 또는 손상 방지 레이어 패턴을 사용할 수 있습니다.

제한된 컨텍스트 정의

도메인 모델은 현실 세계에 존재하는 사용자, 드론, 패키지 등의 항목 표현을 포함합니다. 그렇다고 해서 시스템의 모든 부분에서 동일한 항목에 대해 동일한 표현을 사용해야 한다는 것은 아닙니다.

예를 들어 드론 수리와 예측 분석을 처리하는 하위 시스템은 유지 관리 이력, 이동거리, 사용 기간, 모델 번호, 성능 특징 등과 같이 드론의 물리적 특징을 표현해야 할 수 있습니다. 그러나 배달 예약에서는 그러한 특징을 고려하지 않습니다. 예약 하위 시스템은 드론의 가용 여부와, 수거 및 배달의 ETA를 알기만 하면 됩니다.

이 두 하위 시스템 모두에 대해 하나의 모델을 만들려고 하면 불필요하게 복잡해질 것입니다. 시간이 흘러 이 모델을 확장하게 되면 변경 사항이 개별 하위 시스템을 담당하는 여러 팀을 만족시켜야 하기 때문에 더 어려워집니다. 따라서 동일한 현실 세계 엔터티(이 경우 드론)을 두 가지 다른 컨텍스트에 표현하는 별도의 모델을 설계하는 것이 더 나은 경우가 종종 있습니다. 각 모델은 특정 컨텍스트 내에서 관련된 기능 및 특성만 포함합니다.

바로 DDD의 경계가 있는 컨텍스트 개념이 빛을 발하는 부분입니다. 제한된 컨텍스트는 단순히 특정 도메인 모델이 적용되는 도메인 내의 경계입니다. 이전 다이어그램을 살펴보면 다양한 기능이 단일 도메인 모델을 공유하는지의 여부에 따라 기능을 그룹화할 수 있습니다.

경계가 있는 컨텍스트의 다이어그램

경계가 있는 컨텍스트가 반드시 서로 격리될 필요는 없습니다. 이 다이어그램에서 경계가 있는 컨텍스트를 연결하는 실선은 경계가 있는 두 컨텍스트가 상호 작용하는 지점을 나타냅니다. 예를 들어 배송은 고객 정보를 가져오기 위해 사용자 계정을, 선단에서 드론을 예약하기 위해 드론 관리를 사용합니다.

Domain Driven Design 책에서 Eric Evans는 다른 경계가 있는 컨텍스트와 상호 작용할 때 도메인 모델의 무결성을 유지 관리하기 위한 여러 가지 패턴을 설명합니다. 마이크로 서비스의 기본 원칙 중 하나는 서비스가 잘 정의된 API를 통해 통신하는 것입니다. 이 방법은 Evans가 개방형 호스트 서비스와 게시된 언어라고 칭한 두 패턴에 해당합니다. 개방형 호스트 서비스란 하위 시스템이 다른 하위 시스템과의 통신을 위한 공식 프로토콜(API)를 정의하는 것입니다. 게시된 언어는 다른 팀이 클라이언트를 작성하는 데 사용할 수 있는 양식으로 API를 게시하여 이러한 개념을 확장합니다. 마이크로 서비스를 위한 API 설계에 대한 장에서 OpenAPI 사양(이전의 Swagger)을 사용하여 JSON 또는 YAML 형식으로 표현된 REST API에 대한 언어 중립적 인터페이스 설명을 정의합니다.

이 과정의 나머지 부분에서는 경계가 있는 컨텍스트인 배송에 초점을 맞춥니다.

다음 단계

도메인 분석을 완료한 후 다음 단계는 전략적인 DDD를 적용하여 더욱 정밀하게 도메인 모델을 정의하는 것입니다.

전술적 DDD