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

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

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

Введение

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

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

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

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

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

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

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

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

Сценарий: доставка с помощью дронов

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

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

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

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

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

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

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

Пример. Приложение доставки с помощью дронов

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

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

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

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

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

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

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

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

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

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

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

Дальнейшие действия

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

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

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