Определение границ модели предметной области для каждой микрослужбы
Совет
Это содержимое является фрагментом из электронной книги, архитектуры микрослужб .NET для контейнерных приложений .NET, доступных в документации .NET или в виде бесплатного скачиваемого PDF-файла, который можно читать в автономном режиме.
Границы и размеры модели для каждой микрослужбы необходимо определять не в целях мельчайшего разделения, хотя следует стремиться к минимальному размеру микрослужб. Ваша цель — логичное разделение на основе ваших знаний о предметной области. Главное не размер, а функционал. Кроме того, если для определенной области приложения требуется особая слаженность в связи с большим количеством зависимостей, это также указывает на необходимость создания отдельной микрослужбы. Слаженность позволяет понять, как разделять или объединять микрослужбы. Постепенно изучая предметную область, вы будете снова и снова менять размер микрослужб. Подбор правильного размера — это длительный процесс.
Сэм Ньюмен, признанный специалист по микрослужбам и автор книги Создание микросервисов, рекомендует создавать микрослужбы на основе ограниченного контекста (в рамках части предметной области), как было описано ранее. В некоторых случаях ограниченный контекст может состоять из нескольких физических служб, но не наоборот.
Модель предметной области с определенными сущностями применяется в рамках конкретного ограниченного контекста или микрослужбы. Ограниченный контекст разграничивает применение модели предметной области и дает разработчикам четкое представление о слаженности и возможности независимой разработки отдельных элементов. Такие же цели преследуются для микрослужб.
Кроме того, при выборе структуры вам следует руководствоваться законом Конвея, который гласит, что приложение отражает социальные границы организации, создавшей его. Но иногда верно обратное — программное обеспечение формирует структуру организации. Попробуйте использовать закон Конвея в противоположную сторону и построить границы в соответствии со своими идеальными представлениями о компании, стараясь оптимизировать бизнес-процессы.
Для определения ограниченных контекстов можно использовать шаблон DDD под названием Шаблон сопоставления контекстов. Сопоставляя контексты, вы определяете различные контексты в приложении и их границы. Как правило, существуют различные контексты и границы для каждой небольшой подсистемы. При сопоставлении контекстов становятся очевидными границы между предметными областями. Ограниченный контекст автономен и включает в себя элементы только одной предметной области, например сущности, а также определяет схему интеграции с другими ограниченными контекстами. Этим он похож на микрослужбу: она автономна, реализует определенные возможности предметной области и обеспечивает интерфейсы. Поэтому сопоставление контекстов и ограниченные контексты помогают определить границы модели предметной области для ваших микрослужб.
При разработке крупного приложения вы увидите, как можно разделить его предметную область. Например, специалист по области каталога будет называть сущности в каталоге не так, как специалист по области доставки. Или сущность предметной области пользователя может отличаться по размеру и количеству атрибутов у специалиста по взаимодействию с клиентами, который хочет хранить все сведения о клиенте, и у специалиста по заказам, которому нужны лишь некоторые данные о клиенте. Очень трудно устранить неоднозначность всех терминов предметной области во всех областях в крупном приложении. Но суть в том, что вам и не следует унифицировать термины. Просто примите различия и многообразие каждой предметной области. Если вы попытаетесь создать единую базу данных для всего приложения, это будет непросто, и унифицированный словарь не устроит специалистов по разным областям. Поэтому ограниченные контексты (реализованные как микрослужбы) помогут понять, где можно использовать термины определенной предметной области и где следует разделить систему и создать дополнительные ограниченные контексты с другими предметными областями.
Вы поймете, что правильно выбрали границы и размеры всех ограниченных контекстов и моделей предметной области, если между этими моделями будет существовать несколько прочных связей, и вам не обязательно объединять информацию из нескольких моделей предметной области при выполнении типичных операций в приложении.
При выборе размера модели предметной области для каждой микрослужбы руководствуйтесь следующим принципом: у вас должен быть автономный и максимально изолированный ограниченный контекст, с которым можно работать без постоянного обращения к другим контекстам (другим моделям микрослужб). На рис. 4-10 показано, как несколько микрослужб (несколько ограниченных контекстов) могут иметь собственную модель и как их сущности могут быть определены в зависимости от конкретных требований для каждой предметной области в вашем приложении.
Рис. 4-10. Определение сущностей и границ модели микрослужбы
На рисунке 4-10 показан пример сценария, относящийся к системе управления сетевыми конференциями. Та же сущность отображается как "Пользователи", "Покупатели", "Плательщики" и "Клиенты" в зависимости от ограниченного контекста. Вы определяете несколько ограниченных контекстов, которые можно реализовать как микрослужбы, опираясь на предметные области, выбранные специалистами по этим областям. Как видите, некоторые сущности представлены только в одной модели микрослужбы, например "Платежи" в микрослужбе оплаты. Это будет легко реализовать.
Но некоторые сущности могут иметь разные формы и один идентификатор в различных моделях предметных областей в различных микрослужбах. Например, сущность "Пользователь" определена в микрослужбе управления конференциями. Тот же пользователь и с тем же идентификатором называется "Покупатель" в микрослужбе заказов, "Плательщик" в микрослужбе платежей и "Клиент" в микрослужбе клиентской службы. Дело в том, что каждый специалист в предметной области использует единый язык, по-своему воспринимает пользователя и приписывает ему разные атрибуты. Сущность пользователя в модели микрослужбы для управления конференциями содержит его персональные данные. Но эти атрибуты могут не понадобиться этому же пользователю в роли плательщика в микрослужбе оплаты или в роли клиента в микрослужбе клиентской службы.
Подобный подход проиллюстрирован на рис. 4-11.
Рис. 4-11. Разбиение традиционных моделей данных на несколько моделей предметной области
При декомпозиции традиционной модели данных между ограниченными контекстами у вас может быть несколько сущностей, которые совместно используют одно удостоверение (покупатель также является пользователем), с различными атрибутами в каждом ограниченном контексте. Вы видите, что пользователь присутствует в модели микрослужбы для управления конференциями в виде сущности "Пользователь". А в микрослужбе ценообразования он представлен как сущность "Покупатель" и имеет другие атрибуты и данные. Отдельным микрослужбам или ограниченным контекстам не нужны все данные сущности "Пользователь", только их часть, в зависимости от актуальной проблемы или контекста. Например, в модели микрослужбы ценообразования не нужен адрес или имя пользователя, только идентификатор и статус для определения скидки при назначении цены за место для покупателя.
Сущность "Рабочее место" имеет одно название, но разные атрибуты в каждой модели предметной области. Однако у сущности "Рабочее место" везде одинаковый идентификатор, как у "Пользователя" и "Покупателя".
По сути, существует общее понятие пользователя в различных службах (предметных областях), где он имеет один и тот же идентификатор. Но в каждой модели предметной области указаны разные сведения о сущности пользователя. Поэтому нужен способ сопоставления сущности пользователя в разных предметных областях (или микрослужбах).
Отказ от использования одной сущности пользователя с одинаковым набором атрибутов в разных предметных областях имеет свои преимущества. Одно из них — устранение дублирования. Таким образом, модели микрослужб не будут хранить данные, которые им не нужны. Еще одно преимущество — наличие главной микрослужбы, которая отвечает за определенный тип данных сущности, чтобы обновления и запросы по этому типу данных управлялись только этой микрослужбой.
