Определение границ модели домена для каждой микрослужбы

Подсказка

Это фрагмент из электронной книги «Архитектура микрослужб .NET для контейнеризованных приложений .NET», доступной в документации .NET или в виде бесплатного скачиваемого PDF-файла, который можно прочитать в автономном режиме.

Скачать в формате PDF

Цель при определении границ и размеров модели для каждой микрослужбы состоит не в том, чтобы достичь максимально детализированного разделения, хотя при возможности следует стремиться к небольшим микрослужбам. Вместо этого ваша цель заключается в том, чтобы получить наиболее значимое разделение, руководствуясь знаниями домена. Акцент не на размер, а на бизнес-возможности. Кроме того, если для определенной области приложения требуется четкая согласованность, основанная на большом количестве зависимостей, это также указывает на необходимость одной микрослужбы. Когезия — это способ определить, как разделить или группировать микрослужбы. В конечном счете, приобретая больше знаний о домене, необходимо итеративно адаптировать размер микрослужбы. Поиск правильного размера не является однократным процессом.

Сэм Ньюман, признанный промоутер микрослужб и автор книги "Создание микрослужб", подчеркивает, что следует разрабатывать микрослужбы на основе шаблона ограниченного контекста (BC) (часть архитектуры на основе домена), как было представлено ранее. Иногда БС может состоять из нескольких физических служб, но не наоборот.

Модель домена с определенными сущностями домена применяется в конкретной БС или микрослужбе. BC разделяет применимость модели домена и дает участникам группы разработчиков четкое и общее понимание того, что должно быть сплоченно и что можно разрабатывать независимо. Это те же цели для микрослужб.

Еще одним инструментом, который влияет на ваш выбор проектирования, является закон Конуэя, который утверждает, что приложение будет отражать социальные границы организации, создавшей его. Иногда же наоборот: программное обеспечение формирует организацию компании -the. Вам может потребоваться отменить закон Конуэя и построить границы так, как вы хотите, чтобы компания была организована, опираясь на консультации по бизнес-процессу.

Чтобы определить ограниченные контексты, можно использовать шаблон DDD, называемый шаблоном сопоставления контекста. С помощью сопоставления контекстов вы определяете различные контексты в приложении и их границы. Обычно для каждой небольшой подсистемы обычно используется разные контексты и границы. Карта контекста — это способ определить и сделать явные эти границы между доменами. BC является автономным и включает сведения о одном домене -details, например, сущности домена, и определяет контракты интеграции с другими BC. Это аналогично определению микрослужбы: он является автономным, он реализует определенную возможность домена, и он должен предоставлять интерфейсы. Именно поэтому сопоставление контекста и шаблон привязанного контекста являются хорошим подходом для определения границ модели предметной области микрослужб.

При разработке большого приложения вы увидите, как его модель домена может быть фрагментирована. Например, специалист по домену каталога будет называть сущности по-разному в каталогах и доменах инвентаризации, чем эксперт по домену доставки. Или сущность домена пользователя может отличаться по размеру и количеству атрибутов при работе с экспертом CRM, который хочет хранить все сведения о клиенте, чем для эксперта по заказу домена, который просто нуждается в частичных данных о клиенте. Очень трудно диамбигировать все термины домена во всех доменах, связанных с большим приложением. Но самое главное заключается в том, что вы не должны пытаться объединить термины. Вместо этого примите различия и богатство, предоставляемые каждым доменом. Если вы пытаетесь создать единую базу данных для всего приложения, попытки создания единого словаря будут нелепыми и не будут правильно звучать ни для одного из многочисленных экспертов по предметным областям. Таким образом, BCs (реализованные как микрослужбы) помогут вам уточнить, где можно использовать определенные термины домена и где необходимо разделить систему и создать дополнительные BCs с разными доменами.

Вы узнаете, что вы получили правильные границы и размеры каждой модели BC и домена, если у вас есть несколько сильных связей между моделями предметных областей, и вам обычно не нужно объединять сведения из нескольких моделей домена при выполнении типичных операций приложений.

Возможно, лучший ответ на вопрос о том, насколько большая модель домена для каждой микрослужбы должна быть следующей: она должна иметь автономный bc, как это возможно, что позволяет работать без необходимости постоянно переключаться на другие контексты (модели других микрослужб). На рис. 4–10 можно увидеть, как несколько микрослужб (несколько компьютеров) имеют собственную модель и как их сущности можно определить в зависимости от конкретных требований для каждого из определенных доменов в приложении.

Рис. 4-10. Определение сущностей и границ модели микрослужб

Рис. 4–10 иллюстрирует пример сценария, связанного с системой управления онлайн-конференцией. Эта же сущность отображается как "Пользователи", "Покупатели", "Плательщики" и "Клиенты" в зависимости от ограниченного контекста. Вы определили несколько BC, которые могут быть реализованы как микрослужбы, на основе доменов, определенных для вас экспертами домена. Как видно, есть сущности, которые присутствуют только в одной модели микрослужбы, например платежи в микрослужбе оплаты. Это будет легко реализовать.

Однако у вас могут быть сущности, имеющие другую форму, но разделяющие одну и ту же идентичность в нескольких моделях домена из нескольких микрослужб. Например, сущность пользователя определяется в микрослужбе "Управление конференциями". Этот же пользователь, с тем же удостоверением, является названным покупателем в микросервисе заказа, названным плательщиком в микросервисе оплаты и даже названным клиентом в микросервисе обслуживания клиентов. Это связано с тем, что в зависимости от универсального языка , используемого каждым экспертом домена, пользователь может иметь другую перспективу даже с разными атрибутами. Сущность пользователя в модели микрослужб с именем Conferences Management может иметь большую часть атрибутов персональных данных. Однако тот же пользователь в форме Плательщика в микросервисе Оплаты или в форме Клиента в микросервисе Клиентского обслуживания может не требовать того же списка атрибутов.

Аналогичный подход показан на рис. 4-11.

Рис. 4-11. Разложение традиционных моделей данных на несколько моделей домена

При разложении традиционной модели данных между ограниченными контекстами можно иметь разные сущности, которые разделяют одну и ту же идентичность (покупатель также является пользователем) и имеют разные атрибуты в каждом ограниченном контексте. Вы можете увидеть, как пользователь присутствует в модели микрослужбы Conferences Management в качестве сущности пользователя, а также присутствует в виде сущности Покупателя в микрослужбе ценообразования, с альтернативными атрибутами или сведениями о пользователе, когда он фактически покупатель. Каждая микрослужба или бизнес-компонент может не нуждаться во всех данных, связанных с сущностью пользователя, а только в части этих данных, в зависимости от решаемой проблемы или контекста. Например, в модели микрослужб цен вам не нужен адрес или имя пользователя, только идентификатор (удостоверение) и состояние, которое будет влиять на скидки при ценах на места на покупателя.

Сущность Seat имеет одинаковое имя, но разные атрибуты в каждой модели домена. Однако идентичность Seat определяется на основе того же идентификатора, как это происходит с пользователем и покупателем.

В основном существует общая концепция пользователя, существующего в нескольких службах (доменах), которые совместно используют удостоверение этого пользователя. Но в каждой модели домена могут быть дополнительные или разные сведения о сущности пользователя. Таким образом, необходимо сопоставить сущность пользователя из одного домена (микрослужбы) с другой.

Существует несколько преимуществ, если не использовать ту же сущность пользователя с одинаковым числом атрибутов в разных областях. Одним из преимуществ является сокращение дублирования, чтобы модели микрослужб не имели никаких данных, которые они не нуждаются. Еще одним преимуществом является первичная микрослужба, которая владеет определенным типом данных для каждой сущности, чтобы обновления и запросы для этого типа данных зависят только от этой микрослужбы.

НазадДалее