각 마이크로 서비스에 대한 도메인 모델 경계 식별

팁 (조언)

이 콘텐츠는 .NET Docs 또는 오프라인으로 읽을 수 있는 다운로드 가능한 무료 PDF로 제공되는 컨테이너화된 .NET 애플리케이션용 .NET 마이크로 서비스 아키텍처인 eBook에서 발췌한 내용입니다.

PDF 다운로드

각 마이크로 서비스에 대한 모델 경계 및 크기를 식별할 때의 목표는 가능한 경우 작은 마이크로 서비스로 전환해야 하지만 가능한 가장 세분화된 분리에 이르지 않는 것입니다. 대신, 목표는 도메인 지식에 의해 안내되는 가장 의미 있는 분리에 도착하는 것입니다. 강조는 규모가 아니라 비즈니스 기능에 있습니다. 또한 많은 수의 종속성을 기반으로 애플리케이션의 특정 영역에 대한 명확한 응집력이 필요한 경우 단일 마이크로 서비스의 필요성도 나타냅니다. 응집력은 마이크로 서비스를 분리하거나 그룹화하는 방법을 식별하는 방법입니다. 궁극적으로 도메인에 대한 자세한 정보를 얻는 동안 마이크로 서비스의 크기를 반복적으로 조정해야 합니다. 올바른 크기를 찾는 것은 원샷 프로세스가 아닙니다.

마이크로 서비스의 유명한 프로모터이자 마이크로 서비스 구축 책의 저자인 Sam Newman은 앞에서 소개한 대로 BC(경계 컨텍스트) 패턴(도메인 기반 디자인의 일부)을 기반으로 마이크로 서비스를 디자인해야 한다고 강조합니다. 때때로 BC는 여러 물리적 서비스로 구성될 수 있지만 그 반대의 경우도 마찬가지입니다.

특정 도메인 엔터티가 있는 도메인 모델은 구체적인 BC 또는 마이크로 서비스 내에 적용됩니다. BC는 도메인 모델의 적용 가능성을 구분하고 개발자 팀 구성원에게 응집력이 있어야 하는 항목과 독립적으로 개발할 수 있는 항목에 대한 명확하고 공유된 이해를 제공합니다. 이는 마이크로 서비스에 대해 동일한 목표입니다.

디자인 선택을 알리는 또 다른 도구는 콘웨이의 법입니다. 이 법은 애플리케이션이 이를 생성한 조직의 사회적 경계를 반영한다고 명시하고 있습니다. 때로는 그 반대의 경우가 있습니다. -the 회사의 조직은 소프트웨어에 의해 형성됩니다. 콘웨이의 법을 뒤집고 비즈니스 프로세스 컨설팅 쪽으로 기울어지도록 회사가 조직되기를 원하는 방식으로 경계를 구축해야 할 수도 있습니다.

바인딩된 컨텍스트를 식별하려면 컨텍스트 매핑 패턴이라는 DDD 패턴을 사용할 수 있습니다. 컨텍스트 매핑을 사용하면 애플리케이션의 다양한 컨텍스트와 해당 경계를 식별할 수 있습니다. 예를 들어 작은 하위 시스템마다 다른 컨텍스트와 경계가 있는 것이 일반적입니다. 컨텍스트 맵은 도메인 간에 이러한 경계를 정의하고 명시적으로 만드는 방법입니다. BC는 자율이며 도메인 엔터티와 같은 단일 도메인 -details 세부 정보를 포함하고 다른 BC와의 통합 계약을 정의합니다. 이는 마이크로 서비스의 정의와 유사합니다. 자율적이고, 특정 도메인 기능을 구현하며, 인터페이스를 제공해야 합니다. 이것이 바로 컨텍스트 매핑과 제한된 컨텍스트 패턴이 마이크로 서비스의 도메인 모델 경계를 식별하는 데 적합한 접근 방식인 이유입니다.

대규모 애플리케이션을 디자인할 때 도메인 모델을 조각화할 수 있는 방법을 확인할 수 있습니다. 예를 들어 카탈로그 도메인의 도메인 전문가는 카탈로그 및 인벤토리 도메인에서 엔터티의 이름을 배송 도메인 전문가와 다르게 지정합니다. 또는 사용자 도메인 엔터티는 고객에 대한 부분 데이터가 필요한 주문 도메인 전문가보다 고객에 대한 모든 세부 정보를 저장하려는 CRM 전문가를 다룰 때 특성의 크기와 수가 다를 수 있습니다. 대규모 애플리케이션과 관련된 모든 도메인에서 모든 도메인 용어를 명확하게 구분하기는 매우 어렵습니다. 그러나 가장 중요한 것은 용어를 통합하려고 시도해서는 안된다는 것입니다. 대신 각 도메인에서 제공하는 차이점과 풍요로움을 수락합니다. 전체 애플리케이션에 대한 통합 데이터베이스를 사용하려고 하면 통합 어휘를 시도하는 것이 어색하고 여러 도메인 전문가에게 적합하지 않습니다. 따라서 BC(마이크로 서비스로 구현됨)는 특정 도메인 용어를 사용할 수 있는 위치와 시스템을 분할하고 다른 도메인으로 추가 BC를 만들어야 하는 위치를 명확히 하는 데 도움이 됩니다.

도메인 모델 간에 강력한 관계가 거의 없으며 일반적인 애플리케이션 작업을 수행할 때 일반적으로 여러 도메인 모델의 정보를 병합할 필요가 없는 경우 각 BC 및 도메인 모델의 적절한 경계와 크기를 가지고 있음을 알 수 있습니다.

각 마이크로 서비스에 대한 도메인 모델이 얼마나 큰지에 대한 가장 좋은 대답은 다음과 같습니다. 가능한 한 격리된 자율 BC가 있어야 하며, 이를 통해 다른 컨텍스트(다른 마이크로 서비스의 모델)로 지속적으로 전환하지 않고도 작업할 수 있습니다. 그림 4-10에서는 애플리케이션에서 식별된 각 도메인에 대한 특정 요구 사항에 따라 여러 마이크로 서비스(여러 BC)에 각각 고유한 모델이 있는 방법과 해당 엔터티를 정의할 수 있는 방법을 확인할 수 있습니다.

그림 4-10. 엔터티 및 마이크로 서비스 모델 경계 식별

그림 4-10에서는 온라인 회의 관리 시스템과 관련된 샘플 시나리오를 보여 줍니다. 바인딩된 컨텍스트에 따라 동일한 엔터티가 "사용자", "구매자", "지불자" 및 "고객"으로 표시됩니다. 도메인 전문가가 정의한 도메인을 기반으로 마이크로 서비스로 구현할 수 있는 여러 BC를 확인했습니다. 아시다시피, 결제 마이크로서비스 내에 결제와 같은 단일 마이크로서비스 모델에만 있는 엔터티들이 존재합니다. 구현하기 쉽습니다.

그러나 셰이프가 다르지만 여러 마이크로 서비스의 여러 도메인 모델에서 동일한 ID를 공유하는 엔터티가 있을 수도 있습니다. 예를 들어 사용자 엔터티는 Conferences Management 마이크로 서비스에서 식별됩니다. 동일한 ID를 가진 동일한 사용자는 주문 마이크로 서비스의 구매자 또는 결제 마이크로 서비스의 Payer라는 사용자와 고객 서비스 마이크로 서비스에서 Customer라는 사용자입니다. 이는 각 도메인 전문가가 사용하는 유비쿼터스 언어 에 따라 사용자가 특성이 다르더라도 다른 관점을 가질 수 있기 때문입니다. Conferences Management라는 마이크로 서비스 모델의 사용자 엔터티에는 대부분의 개인 데이터 특성이 있을 수 있습니다. 그러나 마이크로 서비스 결제 또는 마이크로 서비스 고객 서비스의 고객 모양에 있는 동일한 사용자가 동일한 특성 목록을 필요로 하지 않을 수 있습니다.

그림 4-11에서도 비슷한 방법을 보여 줍니다.

그림 4-11. 기존 데이터 모델을 여러 도메인 모델로 분해

바인딩된 컨텍스트 간에 기존 데이터 모델을 분해할 때 각 바인딩된 컨텍스트에서 서로 다른 특성과 동일한 ID(구매자도 사용자임)를 공유하는 다른 엔터티를 가질 수 있습니다. 사용자가 회의 관리 마이크로 서비스 모델에 사용자 엔터티로 표시되는 방식을 확인할 수 있으며 실제로 구매자인 경우 사용자에 대한 대체 특성 또는 세부 정보를 사용하여 가격 책정 마이크로 서비스의 구매자 엔터티 형식으로도 표시됩니다. 각 마이크로 서비스 또는 BC는 해결할 문제 또는 컨텍스트에 따라 사용자 엔터티와 관련된 모든 데이터가 필요하지 않을 수 있습니다. 예를 들어, 가격 책정 마이크로서비스 모델에서는 사용자의 주소나 이름은 필요하지 않고, ID와 상태만 필요합니다. 이는 구매자당 좌석을 가격 책정할 때 할인에 영향을 줍니다.

Seat 엔터티는 이름이 같지만 각 도메인 모델에서 특성이 다릅니다. 그러나 Seat는 사용자 및 구매자와 마찬가지로 동일한 ID를 기반으로 ID를 공유합니다.

기본적으로 여러 서비스(도메인)에 존재하는 사용자의 공유 개념이 있으며, 이 개념은 모두 해당 사용자의 ID를 공유합니다. 그러나 각 도메인 모델에는 사용자 엔터티에 대한 추가 또는 다른 세부 정보가 있을 수 있습니다. 따라서 사용자 엔터티를 한 도메인(마이크로 서비스)에서 다른 도메인으로 매핑하는 방법이 있어야 합니다.

도메인 간에 동일한 수의 특성을 사용하여 동일한 사용자 엔터티를 공유하지 않는 경우 몇 가지 이점이 있습니다. 한 가지 이점은 마이크로 서비스 모델에 필요하지 않은 데이터가 없도록 중복을 줄이는 것입니다. 또 다른 이점은 해당 유형의 데이터에 대한 업데이트 및 쿼리가 해당 마이크로 서비스에서만 구동되도록 엔터티당 특정 형식의 데이터를 소유하는 기본 마이크로 서비스를 갖는 것입니다.

이전다음