Анализ предметной области для моделирования микрослужб

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

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

Введение

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

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

В этой статье и следующем мы рассмотрим следующие действия, применяя их к приложению доставки дронов:

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

2. Затем определите ограничивающие контексты домена. Каждый ограниченный контекст содержит модель предметной области, которая представляет определенную подобласть крупного приложения.

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

4. На основе результатов предыдущего шага идентифицируйте микрослужбы в своем приложении.

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

Сценарий: доставка дронов

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

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

Анализ предметной области

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

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

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

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

Пример: приложение доставки дронов

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

• Доставка размещается в центре схемы, так как она является основной для бизнеса. Все остальное в схеме предназначено для обеспечения этой функции.
• Управление дронами также является основным для бизнеса. Функциональные возможности, тесно связанные с управлением дронами, включают ремонт дронов и использование прогнозного анализа для прогнозирования необходимости обслуживания и обслуживания беспилотных летательных аппаратов.
• Анализ ETA предоставляет оценки времени для погрузки и доставки.
• Сторонний транспорт позволит приложению запланировать альтернативные методы транспортировки, если пакет не может быть отправлен полностью беспилотным летательным аппаратом.
• Общий доступ к дронам — это возможное расширение основного бизнеса. Компания может иметь избыточные мощности беспилотных летательных аппаратов в течение определенных часов, и может арендовать беспилотные летательные аппараты, которые в противном случае будут бездействующими. Этой возможности не будет в первоначальной версии.
• Видеослежка является еще одной областью, которую компания может расширить позже.
• Учетные записи пользователей, выставление счетов и центр вызовов — это поддомены, поддерживающие основной бизнес.

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

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

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

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

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

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

Ограниченные контексты не обязательно изолированы друг от друга. На этой схеме сплошные линии, соединяющие ограниченные контексты, представляют места, где взаимодействуют два ограниченных контекста. Например, область "Доставка" зависит от области "Учетные записи пользователей" для получения информации о клиентах и от области "Управление дронами" для планирования полетов отдельных дронов.

В книге " Дизайн на основе домена" Эрик Эванс описывает несколько шаблонов для поддержания целостности модели домена при взаимодействии с другим ограничивающим контекстом. Одним из основных принципов микрослужб является то, что службы обмениваются данными через четко определенные API. Этот подход соответствует двум шаблонам, которые Эванс называет открытой службой размещения и опубликованным языком. Идея открытой службы размещения заключается в том, что подсистема определяет формальный протокол (API), через который другие подсистемы могут взаимодействовать с ней. Опубликованный язык расширяет эту идею, публикуя API в форме, которую другие команды могут использовать для написания клиентов. В статье "Проектирование API для микрослужб" мы обсудим использование спецификации OpenAPI (ранее известной как Swagger) для определения описания интерфейсов REST API, выраженных в формате JSON или YAML.

В оставшейся части этого руководства мы сконцентрируемся на ограниченном контексте доставки.

Следующие шаги

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

Связанные ресурсы

• Архитектура микрослужб
• Проектирование архитектуры микрослужб
• Определение границ микрослужбы
• Выбор варианта вычислений Azure для микрослужб