애플리케이션 분석 및 분해 경계 확인

완료됨

애플리케이션을 마이크로 서비스 아키텍처로 이동하려면 Fabrikam은 현재 애플리케이션을 평가하고 각 마이크로 서비스의 범위와 경계를 결정해야 합니다. 이 평가에서는 DDD(do기본 기반 디자인) 프레임워크를 사용합니다. 이 프레임워크를 애플리케이션에 적용하는 방법을 살펴보겠습니다.

참고

이 문서에는 완전하고 포괄적인 도메인 분석이 나오지 않습니다. 요점을 설명하기 위해 일부러 간략한 예를 사용합니다. DDD에 대한 자세한 내용은 이 모듈 끝에 있는 요약의 ‘자세히 알아보기’ 섹션을 참조하세요.

도메인 기반 설계란?

DDD는 원래 Erik Evans의 2005년 저서 Domain-Driven Design: Tackling Complexity in the Heart of Software에서 처음 사용되었습니다. 이 방법에는 다음 세 가지 주요 요소가 포함됩니다.

• 핵심 도메인 및 도메인 논리에 집중.
• 도메인 모델의 설계 구조화.
• 시스템을 지속적으로 개선하기 위해 기술 팀과 비즈니스 파트너 간의 반복적인 협업 추진.

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

DDD의 전략적 단계에서는 비즈니스 도메인을 매핑하고 도메인 모델의 제한된 컨텍스트를 정의합니다. 전술적 DDD는 더 상세하게 도메인 모델을 정의하는 경우입니다. 전술적 패턴은 제한된 단일 컨텍스트 내에서 적용됩니다. 마이크로 서비스 아키텍처에서 관심을 갖는 것은 엔터티와 집계 패턴입니다. 이러한 패턴을 적용하면 애플리케이션에서 서비스의 자연스러운 경계를 파악하는 데 도움이 됩니다. 일반적으로 마이크로 서비스는 집계보다 작거나 제한된 컨텍스트보다 클 수 없습니다.

개략적으로 이 프로세스를 다음 4단계로 나눌 수 있습니다.

1. 비즈니스 도메인을 분석하여 애플리케이션의 기능 요구 사항을 파악합니다. 이 단계의 결과는 비공식적인 도메인 설명으로, 보다 공식적인 도메인 모델 세트로 구체화할 수 있습니다.
2. 도메인의 제한된 컨텍스트를 정의합니다. 각각의 제한된 컨텍스트에는 큰 애플리케이션의 특정 하위 도메인을 나타내는 도메인 모델이 포함됩니다.
3. 제한된 컨텍스트 내에서 전술적 DDD 패턴을 적용하여 엔터티, 집계 및 도메인 서비스를 정의합니다.
4. 이전 단계의 결과를 사용하여 애플리케이션의 마이크로 서비스를 확인합니다.

각 단계에서 수행되는 작업을 자세히 살펴보겠습니다.

비즈니스 도메인 분석

DDD는 먼저 비즈니스 도메인을 모델링하고 도메인 모델을 만듭니다. 도메인 모델은 비즈니스 도메인의 추상적 모델입니다. 도메인 지식을 거르고 정리하며 개발자와 도메인 전문가를 위한 공통 언어를 제공합니다.

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

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

제한된 컨텍스트 정의

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

예를 들어 드론 수리 및 예측 분석을 처리하는 하위 시스템은 드론의 여러 물리적 특성을 나타내야 합니다. 이러한 특성에는 유지 관리 기록, 주행 거리, 연령, 모델 번호, 성능 세부 정보가 포함됩니다. 그러나 배달 예약에서는 그러한 특징을 고려하지 않습니다. 예약 하위 시스템은 드론의 가용 여부와 픽업 및 배달의 예상 도착 시간(ETA)만 알면 됩니다.

이러한 두 하위 시스템에 대해 단일 모델을 만들려고 하면 필요한 것보다 더 복잡합니다. 시간이 흐름에 따라 모델을 발전시키기도 어려워집니다. 모든 변경이 별도의 하위 시스템에서 작업하는 여러 팀을 충족시켜야 하기 때문입니다. 동일한 현실 세계 엔터티(이 경우 드론)를 두 가지 다른 컨텍스트에 표현하는 별도의 모델을 설계하는 것이 더 나은 경우가 종종 있습니다. 각 모델은 특정 컨텍스트 내에서 관련된 기능 및 특성만 포함합니다.

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

엔터티, 집계 및 서비스 정의

전술적 DDD는 더 상세하게 도메인 모델을 정의하는 경우입니다. 전술적 패턴은 제한된 단일 컨텍스트 내에서 적용됩니다. 마이크로 서비스 아키텍처에서 관심을 갖는 것은 엔터티와 집계 패턴입니다. 이러한 패턴을 적용하면 애플리케이션에서 서비스의 자연스러운 경계를 파악하는 데 도움이 됩니다. 일반적으로 마이크로 서비스는 집계보다 작거나 제한된 컨텍스트보다 클 수 없습니다.

고려해야 하는 몇 가지 전술적 DDD 패턴이 있습니다.

• 엔터티: 엔터티는 시간이 지나도 지속되는 고유의 ID가 있는 개체입니다. 예를 들어 뱅킹 애플리케이션에서는 고객과 계좌가 엔터티입니다.
• 값 개체: 값 개체에 ID가 없습니다. 특성의 값은 이를 정의하며 변경할 수 없습니다. 값 개체의 대표적인 예로 색, 날짜 및 시간, 통화 값 등이 있습니다.
• 집계: 집계는 하나 이상의 엔터티를 중심으로 하는 일관성 경계를 정의합니다. 집계의 목적은 트랜잭션 고정 항목을 모델링하는 것입니다. 현실은 매우 복잡한 관계로 얽혀있습니다. 고객이 주문을 접수하고, 주문에는 제품이 포함되어 있으며, 제품을 제공하는 공급자가 있는 등 이와 같은 관계가 계속 이어집니다. 애플리케이션이 몇 가지 관련 개체를 수정하는 경우 일관성을 어떻게 유지하나요? 고정 항목을 어떻게 추적하고 적용할까요?
• 도메인 및 애플리케이션 서비스: DDD 용어에서 서비스란 상태를 유지하지 않고 일부 논리를 구현하는 개체입니다. Evans는 do기본 논리를 캡슐화하는 do기본 서비스와 기술 기능을 제공하는 애플리케이션 서비스를 구분합니다. 애플리케이션 서비스에는 일반적으로 사용자 인증 또는 SMS 메시지 전송과 같은 기술 기능이 포함됩니다. 도메인 서비스는 종종 여러 엔터티를 포괄하는 동작을 모델링하는 데 사용됩니다.
• 도메인 이벤트: 도메인 이벤트는 변경이 있을 때 시스템의 다른 부분에 이를 알리는 데 사용됩니다. 이름에서 알 수 있듯이 도메인 이벤트는 도메인 내의 이벤트를 나타내야 합니다. 예를 들어 “테이블에 레코드가 삽입된 것”은 도메인 이벤트가 아닙니다. “배달이 취소된 것”은 도메인 이벤트입니다. 도메인 이벤트는 마이크로 서비스 아키텍처에서 특히 관련이 있습니다. 마이크로 서비스는 분산되고 데이터 저장소를 공유하지 않으므로, 도메인 이벤트를 통해 마이크로 서비스에서 서로 조정할 수 있습니다.

해당 시스템에서 Fabrikam 개발 팀은 다음 엔터티를 확인했습니다.

• 배달
• 패키지
• 드론
• 계정
• 확인
• 알림
• 태그

처음 4개 엔터티(배달, 패키지, 드론, 계정)는 모두 트랜잭션 일관성 경계를 나타내는 집계입니다. 확인 및 알림은 배달의 자식 엔터티입니다. 태그는 패키지의 자식 엔터티입니다.

이 설계의 값 개체에는 Location, ETA, PackageWeight, PackageSize가 포함됩니다.

다음 두 가지 도메인 이벤트가 있습니다.

• 드론이 이동 중인 동안 드론 엔터티는 드론의 위치와 상태(이동 중, 착륙함)를 설명하는 DroneStatus 이벤트를 보냅니다.
• 배달 엔터티는 배달 단계가 변경될 때마다 DeliveryTracking 이벤트를 보냅니다. 이러한 이벤트에는 DeliveryCreated, DeliveryRescheduled, DeliveryHeadedToDropoff 및 DeliveryCompleted가 포함됩니다.

이러한 이벤트는 도메인 모델 안에서 유의미한 사항을 설명합니다. 도메인과 관련한 무언가를 설명하며 특정 프로그래밍 언어 구조와 연관이 없습니다.

개발 팀은 지금까지 설명한 엔터티 중 어디에도 정확히 부합하지는 않는 기능 영역을 하나 더 확인했습니다. 시스템의 일부는 배달 예약 또는 업데이트에 관련된 모든 단계를 조정해야 합니다. 개발 팀은 설계에 두 개의 도메인 서비스를 추가했습니다. Scheduler는 단계를 조정합니다. 감독자는 단계가 실패했거나 시간이 초과되었는지 여부를 감지하기 위해 각 단계의 상태 모니터링합니다.

마이크로 서비스 확인

이제 도메인 모델에서 애플리케이션 설계로 이동할 준비가 되었습니다. 도메인 모델에서 마이크로 서비스를 활용하기 위해 시작하는 방법은 다음과 같습니다.

1. 바인딩된 컨텍스트로 시작합니다. 일반적으로 마이크로 서비스의 기능은 바인딩된 컨텍스트 하나에만 해당해야 합니다. 정의에 따라 제한된 컨텍스트는 특정 도메인 모델의 경계를 표시합니다. 마이크로 서비스가 서로 다른 do기본 모델을 함께 혼합하는 경우 do기본 분석을 구체화해야 할 수도 있다는 신호입니다.
2. 그런 다음 도메인 모델에서 집계를 살펴봅니다. 집계는 마이크로 서비스에 적합한 경우가 많습니다. 잘 디자인된 집계는 잘 설계된 마이크로 서비스의 많은 특징을 보여 줍니다.
   • 집계는 데이터 액세스 또는 메시징과 같은 기술적인 문제가 아닌 비즈니스 요구 사항에서 파생됩니다.
   • 집계에는 높은 기능적 응집력이 있어야 합니다.
   • 집계는 지속성의 경계입니다.
   • 집계는 느슨하게 연결되어야 합니다.
3. 또한 도메인 서비스는 마이크로 서비스에 적합한 경우가 많습니다. 도메인 서비스는 여러 집계의 상태 비저장 작업입니다. 일반적으로 여러 마이크로 서비스를 포함하는 워크플로를 예로 들 수 있습니다. 나중에 드론 배달 애플리케이션에서 do기본 서비스의 예를 볼 수 있습니다.
4. 마지막으로, 비기능적 요구 사항을 고려합니다. 팀 규모, 데이터 유형, 기술, 확장성 요구 사항, 가용성 요구 사항 및 보안 요구 사항과 같은 요소를 확인합니다. 이러한 요인으로 인해 마이크로 서비스를 두 개 이상의 작은 서비스로 더 분해하거나 반대로 수행하고 여러 마이크로 서비스를 하나로 결합할 수 있습니다.

무엇보다 실용성이 중요하며, 도메인 기반 설계는 반복적인 프로세스라는 것을 기억해야 합니다. 확신이 없다면 정교하지 않은 마이크로 서비스로 시작합니다. 여러 기존 마이크로 서비스에서 기능을 리팩터링하는 것보다 마이크로 서비스를 두 개의 작은 서비스로 분할하는 것이 더 쉽습니다.

드론 애플리케이션에 도메인 기반 설계 적용

Fabrikam 애플리케이션의 경우, 이러한 모든 서비스가 기존 모놀리식 애플리케이션에 있습니다. 애플리케이션을 마이크로 서비스로 분해할 수 있는 위치를 식별한 후 패키지 서비스로 시작합니다.

패키지 서비스에는 현재 집중 개발 팀이 있으며 확장성과 관련된 성능 문제를 나타내고 있으며 애플리케이션의 분해를 시작할 수 있는 좋은 후보입니다.