각 마이크로 서비스의 도메인 모델 경계 식별
팁
이 콘텐츠는 eBook, 컨테이너화된 .NET 애플리케이션을 위한 .NET 마이크로 서비스 아키텍처에서 발췌한 것이며, .NET 문서에서 제공되거나 오프라인 상태에서도 읽을 수 있는 PDF(무료 다운로드 가능)로 제공됩니다.
가능하면 마이크로 서비스가 작아야 하지만 각 마이크로 서비스에 대한 모델 경계 및 크기를 식별할 때 세분화하여 분리하지 않는 것이 좋습니다. 대신, 도메인 지식에 의해 설명된 가장 적합한 분리로 이동하는 것이 목적입니다. 중요한 점은 크기가 아닌 비즈니스 용량입니다. 또한 많은 수의 종속성을 기반으로 애플리케이션의 특정 부분에 필요한 응집력이 있는 경우 단일 마이크로 서비스가 필요하다는 것을 나타냅니다. 응집력은 마이크로 서비스를 분리하거나 그룹화하는 방법을 식별하는 방법입니다. 궁극적으로 도메인에 대한 더 많은 지식을 확보하는 동안 마이크로 서비스의 크기를 반복적으로 활용해야 합니다. 적절한 크기를 찾는 것은 원샷 프로세스가 아닙니다.
마이크로 서비스의 선구자이며 마이크로 서비스 빌드라는 책의 저자인 Sam Newman은 앞서 소개한 대로 BC(경계가 지정된 컨텍스트) 패턴(도메인 기반 디자인의 일부)에 따라 마이크로 서비스를 디자인해야 한다고 강조합니다. 경우에 따라 BC는 몇 가지 물리적 서비스로 구성되지만 그 반대의 경우는 불가능합니다.
특정 도메인 엔터티를 사용하는 도메인 모델은 특정 BC 또는 마이크로 서비스 내에서 적용됩니다. BC는 도메인 모델의 적용 가능성을 제한하고 개발자 팀 멤버에게 화합되어야 하는 기능 및 독립적으로 개발할 수 있는 기능에 대한 명확하고 공유된 이해를 제공합니다. 마이크로 서비스에 대한 동일한 목표입니다.
디자인을 선택했다고 알려주는 또 다른 도구는 Conway's law입니다. 여기서는 애플리케이션이 생성한 조직의 사회적 경계를 반영합니다. 그러나 때로는 반대가 맞습니다. 회사의 조직은 소프트웨어로 구성됩니다. 회사를 구성하려는 방식으로 Conway's law를 되돌리고 경계를 빌드해야 할 수도 있습니다. 그러면 비즈니스 프로세스 컨설팅으로 기울어집니다.
바인딩된 컨텍스트를 식별하려면 컨텍스트 매핑 패턴이라는 DDD 패턴을 사용할 수 있습니다. 컨텍스트 매핑을 사용하여 애플리케이션 및 해당 경계에서 다양한 컨텍스트를 식별합니다. 예를 들어 일반적으로 작은 하위 시스템에 다른 컨텍스트 및 경계가 있습니다. 컨텍스트 맵은 도메인 간의 해당 경계를 정의하고 명시적으로 지정하는 방법입니다. BC는 자율적이며 도메인 엔터티와 같은 단일 도메인의 세부 정보를 포함하며 다른 BC와의 통합 계약을 정의합니다. 마이크로 서비스의 정의와 비슷하게 자율적이며 특정 도메인 기능을 구현하고 인터페이스를 제공해야 합니다. 따라서 컨텍스트 매핑 및 바인딩된 컨텍스트 패턴은 마이크로 서비스의 도메인 모델 경계를 식별하기 위한 좋은 방법입니다.
대규모 애플리케이션을 디자인할 때 도메인 모델을 조각화할 수 있는 방법이 표시됩니다. 예를 들어 카탈로그 도메인의 도메인 전문가는 배송 도메인 전문가와 달리 카탈로그 및 인벤토리 도메인에서 엔터티 이름을 다르게 지정합니다. 또는 고객에 대한 불완전한 데이터가 필요한 주문 도메인 전문가와 달리 고객에 대한 모든 세부 정보를 저장하려는 CRM 전문가를 다룰 때 사용자 도메인 엔터티는 특성의 크기와 수가 다를 수 있습니다. 대규모 애플리케이션과 관련된 모든 도메인에서 모든 도메인 용어를 명확히 구분하는 것은 어렵습니다. 하지만 가장 중요한 점은 용어를 통합하려고 해서는 안 된다는 것입니다. 대신 각 도메인에서 제공하는 차이점과 다양성을 수용하세요. 전체 애플리케이션에 통합 데이터베이스를 보유하는 경우 통합 어휘를 사용하는 것은 이상하고 여러 도메인 전문가도 옳다고 여기지 않습니다. 따라서 BC(마이크로 서비스로 구현됨)는 다른 도메인을 사용하여 특정 도메인 용어를 사용할 수 있는 위치 및 시스템을 나누고 추가 BC를 만들어야 하는 위치를 명시할 수 있습니다.
도메인 모델 간에 강력한 관계가 거의 없고 일반적인 애플리케이션 작업을 수행할 때 일반적으로 여러 도메인 모델에서 정보를 병합할 필요가 없는 경우, 각 BC와 도메인 모델의 올바른 경계와 크기를 알 수 있습니다.
아마도 각 마이크로 서비스의 도메인 모델 크기에 대한 질문에 최상의 답변은 다음과 같습니다. 가능한 한 격리된 자율적인 BC가 있어야만 다른 컨텍스트로 전환하지 않고도 작업할 수 있습니다(다른 마이크로 서비스의 모델). 그림 4-10에서 애플리케이션에서 식별된 도메인 각각에 대한 특정 요구 사항에 따라 고유한 모델이 있는 마이크로 서비스(여러 BC)의 수 및 해당 엔터티를 정의할 수 있는 방법을 확인할 수 있습니다.
그림 4-10 엔터티 및 마이크로 서비스 모델 경계 식별
그림 4-10은 온라인 회의 관리 시스템과 관련된 샘플 시나리오를 보여줍니다. 바인딩된 컨텍스트에 따라 동일한 엔터티가 "사용자", "구매자", "지급인" 및 "고객"으로 표시됩니다. 도메인 전문가가 정의한 도메인에 따라 마이크로 서비스로 구현할 수 있는 몇 가지 BC를 식별했습니다. 볼 수 있듯이 결제 마이크로 서비스의 결제와 같은 단일 마이크로 서비스 모델에만 있는 엔터티가 있습니다. 구현하기 쉽습니다.
그러나 다른 셰이프가 있지만 여러 마이크로 서비스의 여러 도메인 모델에서 동일한 ID를 공유하는 엔터티가 있을 수 있습니다. 예를 들어 사용자 엔터티는 회의 관리 마이크로 서비스에서 식별됩니다. 동일한 ID를 사용하는 동일한 사용자는 주문 마이크로 서비스의 구매자이거나 결재 마이크로 서비스의 결재자이고 고객 서비스 마이크로 서비스의 고객이라고도 할 수 있습니다. 이로 인해 각 도메인 전문가가 사용하는 유비쿼터스 언어에 따라 사용자에게는 다양한 특성을 가진 다른 관점이 있을 수 있습니다. 회의 관리라는 마이크로 서비스 모델의 사용자 엔터티에는 대부분의 개인 데이터 특성이 있을 수 있습니다. 그러나 결재 마이크로 서비스의 결재자 셰이프나 고객 서비스 마이크로 서비스의 고객 셰이프인 동일한 사용자에게는 동일한 특성 목록이 필요하지 않습니다.
그림 4-11에 유사한 방법이 나와있습니다.
그림 4-11 일반적인 데이터 모델을 여러 도메인 모델로 분해
바인딩된 컨텍스트 간에 기존 데이터 모델을 분해할 때 각 바운딩된 컨텍스트에서 서로 다른 특성을 가진 동일한 ID(구매자도 사용자임)를 공유하는 여러 엔터티를 가질 수 있습니다. 사용자가 실제로 구매자일 때 사용자에 대한 대체 특성 및 세부 정보를 사용하여 사용자 엔터티로 회의 관리 마이크로 서비스 모델에 존재하고 가격 책정 마이크로 서비스의 구매자 형식으로 존재하는 방법을 확인할 수 있습니다. 각 마이크로 서비스 또는 BC에는 해결할 문제 또는 컨텍스트에 따라 사용자 엔터티와 관련된 모든 데이터가 아닌 일부가 필요합니다. 예를 들어 가격 책정 마이크로 서비스 모델에서 사용자의 주소나 이름이 필요하지 않고 ID(ID) 및 상태만이 필요합니다. 이는 구매자 당 좌석의 가격을 책정할 때 할인에 영향을 줍니다.
사용자 엔터티는 각 도메인 모델에서 동일한 이름과 다른 특성을 사용합니다. 그러나 사용자와 구매자에서 발생하는 대로 사용자는 동일한 ID를 기반으로 ID를 공유합니다.
기본적으로 해당 사용자의 ID를 모두 공유하는 여러 서비스(도메인)에 있는 사용자의 공유 개념이 있습니다. 하지만 각각의 도메인 모델에는 사용자 엔터티에 대한 추가 세부 정보가 있을 수 있습니다. 따라서 도메인(마이크로 서비스) 간에 사용자 엔터티를 매핑하는 방법이 있어야 합니다.
도메인 간에 동일한 특성 수를 가진 동일한 사용자 엔터티를 공유하지 않는 몇 가지 이점이 있습니다. 이점 중 하나는 마이크로 서비스 모델에는 필요하지 않은 데이터가 없도록 중복을 줄이는 것입니다. 또 다른 이점은 해당 형식의 데이터에 대한 업데이트 및 쿼리가 해당 마이크로 서비스에 의해서만 발생하도록 특정 형식의 엔터티 당 데이터를 소유하는 기본 마이크로 서비스가 있는 것입니다.
.NET