Анализ приложения и определение границ декомпозиции

Завершено

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

Заметка

В этой статье не показан полный и комплексный анализ домена. Мы намеренно держали пример кратким, чтобы проиллюстрировать основные моменты. Дополнительные сведения о DDD см. в разделе "Дополнительные сведения" в сводке в конце этого модуля.

Что такое проектирование на основе домена?

DDD — это подход к проектированию системы, первоначально введенный Эриком Эвансом в книге Domain-Driven Дизайн 2005 года: управление сложностью в сердце программного обеспечения. Этот подход включает три ключевых элемента:

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

DDD предоставляет фреймворк, который помогает значительно продвинуться к созданию набора хорошо разработанных микросервисов. Он имеет две различные фазы, стратегическая и тактическая. В стратегическом DDD определяется масштабируемая структура системы. Стратегический DDD помогает гарантировать, что архитектура остается сосредоточенной на бизнес-возможностях. Тактический DDD предоставляет набор шаблонов проектирования, которые можно использовать для создания модели домена. Эти шаблоны включают сущности, агрегаты и доменные службы. Эти тактические шаблоны помогают создавать микрослужбы, которые слабо связаны и сплоченны.

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

На высоком уровне этот процесс можно разбить на четыре этапа:

1. Анализ бизнес-домена для понимания функциональных требований приложения. Выходные данные этого шага являются неофициальным описанием домена, который можно уточнить в более формальном наборе моделей предметной области.
2. Определите ограниченные контексты домена. Каждый ограниченный контекст содержит модель домена, представляющую определенный поддомен большего приложения.
3. В ограниченном контексте примените тактические шаблоны DDD для определения сущностей, агрегатов и доменных служб.
4. Определите микрослужбы в приложении с помощью результатов предыдущего шага.

Давайте рассмотрим, что происходит на каждом из этих шагов.

Анализ бизнес-домена

DDD начинается с моделирования бизнес-домена и создания модели домена. Модель домена — это абстрактная модель бизнес-домена. Он дистиллирует и упорядочивает знания о домене, и предоставляет общий язык для разработчиков и экспертов по домену.

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

По мере заполнения схемы можно начать определять дискретные поддомены. Какие функции тесно связаны? Какие функции являются основными для бизнеса и которые предоставляют вспомогательные услуги? Что такое граф зависимостей? На этом начальном этапе вы не обеспокоены технологиями или сведениями о реализации. При этом следует отметить место, в котором приложение должно интегрироваться с внешними системами, такими как CRM, системы обработки платежей или системы выставления счетов.

Определение ограничивающих контекстов

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

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

Если мы пытаемся создать одну модель для обеих этих подсистем, это сложнее, чем нам нужно. Модель также становится сложнее развиваться с течением времени, так как любые изменения должны удовлетворять нескольким командам, работающим над отдельными подсистемами. Часто лучше разрабатывать отдельные модели, представляющие одну и ту же сущность реального мира (в данном случае дрон) в двух разных контекстах. Каждая модель содержит только компоненты и атрибуты, относящиеся к определенному контексту.

Этот подход заключается в том, что концепция DDD ограниченных контекстов вступает в игру. Ограничивающий контекст — это просто граница в домене, в котором применяется определенная модель домена. Рассматривая предыдущую схему, мы можем группировать функциональные возможности в зависимости от того, используют ли различные функции одну общую модель предметной области.

Определение сущностей, агрегатов и служб

Тактический подход DDD заключается в более точном определении ваших доменных моделей. Тактические шаблоны применяются в одном ограниченном контексте. В архитектуре микрослужб мы заинтересованы в сущностях и агрегатных шаблонах. Применение этих шаблонов помогает нам определить естественные границы для служб в нашем приложении. В качестве общего принципа микрослужба не должна быть меньше агрегата и не больше ограниченного контекста.

Существует несколько тактических шаблонов DDD, которые следует учитывать:

• Сущности: Сущность — это объект с уникальной идентичностью, которая сохраняется со временем. Например, в банковском приложении клиенты и счета являются сущностями.
• Объекты-значения: Объект-значение не имеет идентичности. Значения его атрибутов определяют его и неизменяемы. Типичные примеры объектов значений включают цвета, даты и время и значения валют.
• агрегаты: агрегат определяет границу согласованности для одной или нескольких сущностей. Цель агрегата — моделировать инварианты транзакций. Вещи в реальном мире имеют сложные сети отношений. Клиенты создают заказы, заказы содержат продукты, продукты имеют поставщиков и т. д. Если приложение изменяет несколько связанных объектов, как она гарантирует согласованность? Как отслеживать инварианты и применять их?
• доменных служб и служб приложений: в терминологии DDD служба — это объект, реализующий некоторую логику без каких-либо состояний. Эванс различает доменные службы, которые инкапсулируют логику домена и службы приложений, которые обеспечивают техническую функциональность. Службы приложений обычно включают технические функции, такие как проверка подлинности пользователя или отправка SMS-сообщения. Доменные службы часто используются для моделирования поведения, охватывающего несколько сущностей.
• события домена: события домена можно использовать для уведомления других частей системы о том, что происходит. Как предполагает имя, события домена должны означать что-то в домене. Например, "запись была вставлена в таблицу" не является событием домена. "Доставка отменена" — это событие домена. События домена особенно важны в архитектуре микрослужб. Так как микрослужбы распределены и не совместно используют хранилища данных, события домена позволяют микрослужбам координироваться друг с другом.

В своей системе команда разработки Fabrikam определила следующие сущности:

• Доставка
• Пакет
• Дрон
• Счет
• Подтверждение
• Уведомление
• Метка

Первые четыре сущности, доставка, пакет, дрон и учетная запись — это все агрегаты, представляющие границы согласованности транзакций. Подтверждения и уведомления — это дочерние сущности поставок. Теги — это дочерние сущности пакетов.

Объекты значений в этом дизайне включают Location, ETA, PackageWeight и PackageSize.

Существует два события домена:

• В то время как беспилотный летательный аппарат находится в полете, сущность дрона отправляет события DroneStatus, описывающие расположение и состояние дрона, например, в полете, приземлились.
• Служба доставки отправляет события отслеживания доставки каждый раз, когда изменяется этап доставки. К этим событиям относятся DeliveryCreated, DeliveryRescheduled, DeliveryHeadedToDropoff и DeliveryCompleted.

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

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

Определение микрослужб

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

1. Начните с ограниченного контекста. Как правило, функциональные возможности микрослужбы не должны охватывать более одного ограниченного контекста. По определению ограниченный контекст помечает границу конкретной модели домена. Если ваша микрослужба объединяет различные модели предметных областей, это может указывать на необходимость уточнения анализа вашей предметной области.
2. Затем ознакомьтесь с агрегатами в модели домена. Агрегаты часто являются хорошими кандидатами для микрослужб. Хорошо разработанный агрегат показывает многие характеристики хорошо разработанной микрослужбы:
   • Агрегат является производным от бизнес-требований, а не технических проблем, таких как доступ к данным или обмен сообщениями.
   • Агрегат должен иметь высокую функциональную сплоченность.
   • Агрегат — это граница сохраняемости.
   • Агрегаты должны быть слабо связаны.
3. Доменные службы также являются хорошими кандидатами для микрослужб. Доменные службы — это бестранзакционные операции с множественными сущностями. Типичным примером является рабочий процесс, который включает несколько микрослужб. Позже мы видим пример доменной службы в приложении доставки дронов.
4. Наконец, рассмотрите нефункциональные требования. Ознакомьтесь с такими факторами, как размер группы, типы данных, технологии, требования к масштабируемости, требования к доступности и требования к безопасности. Эти факторы могут привести к дальнейшему разложению микрослужбы на две (или более) небольшие службы, или сделать противоположное и объединить несколько микрослужб в одну.

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

Применение архитектуры на основе домена к приложению беспилотных летательных аппаратов

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

В настоящее время пакетная служба имеет сфокусированную команду разработки, демонстрирует проблемы производительности, касающиеся масштабируемости, и является подходящим кандидатом для начала декомпозиции приложения.