Анализ предметной области для моделирования микрослужб
Одной из основных проблем, связанных с микрослужбами, является определение границ отдельных служб. Общее правило заключается в том, что служба должна выполнять "одну вещь", но для применения этого правила требуется тщательное мышление. Механического процесса, создающего "правильную" структуру, не существует. Необходимо глубоко подумать о вашем бизнес-домене, требованиях, характеристиках архитектуры (также известных как нефункциональный требования) и целях. В противном случае можно столкнуться с непродуманной структурой, в которой есть некоторые нежелательные характеристики, такие как скрытые зависимости между службами, тесная взаимозависимость или плохо разработанные интерфейсы. В этой статье показан подход на основе домена к проектированию микрослужб. Оценка границ служб — это постоянные усилия по эволюции рабочих нагрузок. Иногда оценка приводит к переопределенным определениям существующих границ, требующих дополнительной разработки приложений для изменения.
В этой статье в качестве примера используется служба доставки дронов. Дополнительные сведения о сценарии и соответствующей эталонной реализации см. здесь.
Введение
Микрослужбы нужно разрабатывать с учетом бизнес-возможностей, а не горизонтальных слоев, таких как доступ к данным или обмен сообщениями. Кроме того, службы должны иметь слабую взаимозависимость и высокую функциональную слаженность. Микрослужбы имеют слабую взаимозависимость, если можно изменить одну службу без необходимости одновременного обновления других служб. Микрослужба считается слаженной, если у нее есть одна определенная цель, например управление учетными записями пользователей или отслеживание истории поставок. Служба должна содержать знания о предметной области и отделять эти знания от клиентов. Например, клиент должен иметь возможность запланировать полет дрона, не зная подробностей алгоритма планирования или управления парком дронов. Характеристики архитектуры должны быть определены для каждой микрослужбы, чтобы соответствовать его проблемам домена, а не определяться для всей системы. Например, микрослужба, доступная к клиенту, может иметь производительность, доступность, отказоустойчивость, безопасность, возможность тестирования и гибкость. Микрослужба серверной части может иметь только отказоустойчивость и безопасность. Если микрослужбы имеют синхронные связи друг с другом, зависимость между ними часто создает необходимость совместно использовать одинаковые характеристики архитектуры.
Предметно-ориентированное проектирование (DDD) предоставляет платформу, которая может помочь в разработке набора хорошо продуманных микрослужб. Этот алгоритм имеет два отдельных этапа: стратегический и тактический. На стратегическом этапе определяется масштабная структура системы. Этот этап помогает гарантировать, что архитектура ориентирована на бизнес-возможности. На тактическом этапе DDD предоставляется набор конструктивных шаблонов, которые можно использовать для создания модели предметной области. Эти шаблоны включают в себя сущности, статистические выражения и службы предметных областей. Эти тактические шаблоны помогают создавать микрослужбы, имеющие слабую взаимозависимость и хорошую слаженность.
В этой статье и следующем мы рассмотрим следующие действия, применяя их к приложению доставки дронов:
Начните с анализа предметной области бизнеса, чтобы разобраться в функциональных требованиях приложения. В результате вы получите неформальное описание предметной области, которое можно разделить на более формальный набор моделей предметных областей.
Затем определите ограниченные контексты предметной области. Каждый ограниченный контекст содержит модель предметной области, которая представляет определенную подобласть крупного приложения.
В рамках ограниченного контекста примените тактические шаблоны DDD, чтобы определить сущности, статистические выражения и службы предметных областей.
На основе результатов предыдущего шага идентифицируйте микрослужбы в своем приложении.
В этой статье мы рассмотрим первые три шага, которые в первую очередь связаны с DDD. В следующей статье мы определим микрослужбы. Важно помнить, что предметно-ориентированное проектирование — это итеративный текущий процесс. Ограничения службы не зафиксированы. По мере развития приложения можно разбить службу на несколько небольших служб.
Примечание.
Эта статья не предназначена для демонстрации полного и исчерпывающего анализа предметной области. Мы намеренно держали пример кратким, чтобы проиллюстрировать основные моменты. Общие сведения о проблемно-ориентированном проектировании можно найти в одноименной книге Эрика Эванса (Eric Evans), в которой был впервые представлен этот термин. Другим хорошим справочником является книга Вона Вернона (Vaughn Vernon) Реализация методов предметно-ориентированного проектирования.
Сценарий: доставка дронов
Компания Fabrikam запускает службу доставки беспилотными летательными аппаратами. Она управляет парком таких аппаратов. Компании регистрируются в этой службе и пользователи могут отправлять заявки на использование дрона для доставки товаров компаний. Когда клиент планирует отгрузку, серверная система назначает аппарат и сообщает пользователю предполагаемое время доставки. В ходе доставки клиент может отслеживать местоположение дрона, получая актуальные сведения об ожидаемом времени доставки.
Этот сценарий довольной сложный, так как его этапы включают планирование загруженности беспилотных летательных аппаратов, отслеживание посылок, управление учетными записями пользователей, а также хранение и анализ исторических данных. Кроме того, компания Fabrikam хочет быстро выйти на рынок, а затем быстро повторить этот процесс, добавив новые функции и возможности. Приложение должно работать в масштабе облака с высоким целевым уровнем обслуживания. Компания также ожидает, что в разных частях системы требования к хранению данных и выполнению запросов будут очень отличаться. С учетом всех этих факторов Fabrikam выбрала архитектуру микрослужб для приложения доставки беспилотными летательными аппаратами.
Анализ предметной области
Используя подход DDD, можно создавать микрослужбы так, чтобы каждая форма службы естественным образом совпадала с функциональным бизнес-требованием. Так вы сможете избежать ловушки, когда ограничения организации или технологии будут определять структуру.
Прежде чем написать код, необходимо иметь общее представление о создаваемой системе. DDD начинается с моделирования предметной области бизнеса и создания ее модели. Модель предметной области является абстрактной моделью предметной области бизнеса. Она извлекает и организует знания о предметной области, а также предоставляет общий язык для разработчиков и экспертов соответствующей сферы.
Начните с сопоставления схемы всех бизнес-функций и их связей. Эта работа обычно выполняется совместно с привлечением специалистов по предметной области, архитекторов программного обеспечения и других заинтересованных лиц. При этом использовать какой-либо конкретный формальный способ не требуется. Нарисуйте схему на бумаге или доске.
Создавая схему, можно начать определять дискретные подобласти. Какие функции тесно связаны? Какие функции являются основными для бизнеса, а какие предоставляют вспомогательные службы? Что такое схема зависимостей? На начальном этапе технологии и подробности реализации не важны. Все же следует отметить место, где приложение нужно будет интегрировать с внешними системами, такими как CRM, система обработки оплаты или выставления счетов.
Пример: приложение доставки дронов
После первоначального анализа предметной области команда Fabrikam создала приблизительный эскиз, представляющий предметную область "Доставка с помощью дронов".
- Функция Доставка размещается в центре схемы, так как она является основной для бизнеса. Все остальное в схеме предназначено для обеспечения этой функции.
- Управление дронами также является ключевой бизнес-функцией. Функция, которая тесно связана с управлением дронами, включает их ремонт и использование прогнозного анализа для прогнозирования, когда дроны нуждаются в обслуживании.
- Анализ ETA предоставляет оценки времени приема и доставки.
- Транспортировка сторонними лицами позволяет приложению планировать другие способы транспортировки, если груз невозможно полностью отправить с помощью дрона.
- Совместное использование дрона является возможным расширением основной бизнес-функции. В определенные часы у компании может быть избыточное количество дронов, которые можно сдавать в аренду, чтобы они не простаивали. Этой возможности не будет в первоначальной версии.
- Видеонаблюдение является еще одной областью расширения деятельности для компании.
- Учетные записи пользователей, Выставление счетов и Центр обработки вызовов — это подобласти, используемые для поддержки основных бизнес-процессов.
Обратите внимание, что на этом этапе никаких решений о реализации и технологиях не принималось. Некоторые из подсистем могут включать внешние программные системы или сторонние службы. Тем не менее приложению необходимо взаимодействовать с этими системами и службами, поэтому важно включить их в модель предметной области.
Примечание.
Если приложение зависит от внешней системы, есть риск, что может произойти утечка схемы данных внешней системы или API в приложение, что может скомпрометировать архитектурный проект. Это особенно верно в отношении устаревших систем, которые могут не следовать современным рекомендациям и могут использовать сложные схемы данных или устаревшие API. В этом случае важно иметь четко определенную границу между внешними системами и приложением. Рекомендуется использовать шаблон Strangler Fig или шаблон уровня защиты от коррупции для этой цели.
Определение ограниченных контекстов
Модель предметной области включает представления реальных вещей — пользователей, дронов, грузов и т. д. Однако это не значит, что каждая часть системы должна использовать одни и те же представления для одних и тех же вещей.
Например, подсистемы, обрабатывающие ремонт дронов и прогнозный анализ, должны представлять множество физических характеристик беспилотных летательных аппаратов, таких как журнал обслуживания, пробег, возраст, номер модели, характеристики производительности и т. д. Но при планировании доставки это нам неинтересно. Подсистеме планирования необходимо знать, доступен ли дрон, а также предполагаемое время для приема и доставки (ETA).
Если бы мы попытались создать единую модель для обеих этих подсистем, это было бы излишне сложным. С течением времени модель будет все сложнее видоизменять, так как любые изменения должны будут удовлетворять несколько команд, работающих над отдельными подсистемами. Поэтому зачастую лучше разрабатывать отдельные модели, которые представляют один и тот же объект реального мира (в данном случае дрон) в двух разных контекстах. Каждая модель содержит только те функции и атрибуты, которые имеют отношение к конкретному контексту.
Именно здесь вступает в действие концепция ограниченных контекстов, существующая в рамках предметно-ориентированного проектирования. Ограниченный контекст — это просто граница внутри предметной области, где применяется конкретная модель предметной области. Рассматривая предыдущую схему, можно группировать функции в зависимости от того, будут ли различные функции использовать одну модель предметной области.
Ограниченные контексты не обязательно изолировать друг от друга. На этой схеме сплошные линии, соединяющие ограниченные контексты, представляют места, где взаимодействуют два ограниченных контекста. Например, область "Доставка" зависит от области "Учетные записи пользователей" для получения информации о клиентах и от области "Управление дронами" для планирования полетов отдельных дронов.
В книге Проблемно-ориентированное проектирование Эрик Эванс описывает шаблоны по поддержке целостности модели предметной области при взаимодействии с другим ограниченным контекстом. Одним из основных принципов микрослужб является то, что службы обмениваются данными через четко определенные API. Этот подход соответствует двум шаблонам, которые Эванс называет открытой службой размещения и опубликованным языком. Идея открытой службы размещения заключается в том, что подсистема определяет формальный протокол (API), через который другие подсистемы могут взаимодействовать с ней. Опубликованный язык расширяет эту идею, публикуя API в форме, которую другие команды могут использовать для написания клиентов. В статье "Проектирование API для микрослужб" мы обсудим использование спецификации OpenAPI (ранее известной как Swagger) для определения описания интерфейсов REST API, выраженных в формате JSON или YAML.
В оставшейся части этого руководства мы сконцентрируемся на ограниченном контексте доставки.
Следующие шаги
После завершения анализа домена следующий шаг — применить тактический DDD, чтобы определить модели домена с большей точностью.