Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Одной из основных проблем, связанных с микрослужбами, является определение границ отдельных служб. Общее правило заключается в том, что служба должна выполнять только одну вещь, но для применения этого правила требуется тщательное мышление. Нет никакого механического процесса, который создает правильный дизайн. Необходимо глубоко подумать о вашем бизнес-домене, требованиях, характеристиках архитектуры (также известных как нефункциональные требования) и целях. В противном случае вы рискуете создать неструктурированную структуру, которая имеет скрытые зависимости между службами, жесткой связью или плохо разработанными интерфейсами. В этой статье показан подход на основе домена к проектированию микрослужб. Оценка границ службы — это продолжающаяся работа по эволюции рабочих нагрузок. Иногда оценка приводит к переопределенным границам, которые требуют больше разработки приложений для удовлетворения изменений.
В этой статье в качестве примера используется служба доставки дронов. Дополнительные сведения о сценарии и соответствующей эталонной реализации см. в разделе "Проектирование архитектуры микрослужб".
Введение
Проектирование микрослужб вокруг бизнес-возможностей, а не горизонтальных слоев, таких как доступ к данным или обмен сообщениями. Убедитесь, что микрослужбы имеют свободное соединение и высокую функциональную сплоченность. Микрослужбы слабо связаны , если вы можете изменить одну службу без обновления других служб одновременно. Микрослужба является сплоченной , если она имеет единую, хорошо определенную цель, например управление учетными записями пользователей или историей доставки. Службы должны инкапсулировать знания домена и абстрагировать эти знания от клиентов. Например, клиент может запланировать беспилотный летательный аппарат без знания алгоритма планирования или управления парком дронов.
Необходимо определить характеристики архитектуры для каждой микрослужбы, чтобы соответствовать его проблемам домена, а не определять их для всей системы. Например, микрослужба, доступная к клиенту, может требовать производительности, доступности, отказоустойчивости, безопасности, тестирования и гибкости. Для внутренней микрослужбы может потребоваться только отказоустойчивость и безопасность. Если микрослужбы взаимодействуют синхронно, их зависимость среды выполнения часто требует совместного использования одинаковых характеристик архитектуры.
Проектирование на основе домена (DDD) предоставляет платформу, которая поддерживает проектирование хорошо структурированных микрослужб. DDD имеет стратегический этап и тактический этап. В стратегическом DDD вы определяете масштабируемую структуру системы. Стратегический DDD гарантирует, что ваша архитектура остается сосредоточенной на бизнес-возможностях. Тактический DDD предоставляет шаблоны проектирования, которые можно использовать для создания модели домена. Эти шаблоны включают в себя сущности, статистические выражения и службы предметных областей. Эти тактические шаблоны помогают создавать микрослужбы, которые слабо связаны и сплоченны.
Концепция универсального языка является центральным в DDD. Это общий словарь, который разработчики и эксперты домена создают вместе в каждом ограниченном контексте. Команды используют этот язык последовательно в беседах, документации и коде. Если одни и те же термины означают то же самое во всех этих областях, команды сокращают недоразумения и создают модели предметных областей, которые точно отражают бизнес-намерения. Каждый ограниченный контекст может иметь свой собственный повсеместный язык, что означает, что одно слово (например, учетная запись) имеет разные значения в разных контекстах.
В этой статье и связанной статьей тактического DDD представлены следующие шаги и их применение к приложению доставки дронов:
Анализ бизнес-домена для понимания функциональных требований приложения. Выходные данные этого шага — это неформальное описание домена, которое можно уточнить в более формальном наборе моделей предметной области.
Определите ограниченные контексты домена. Каждый ограниченный контекст содержит модель домена, представляющую определенный поддомен большего приложения.
Применяйте тактические шаблоны DDD в ограниченном контексте для определения сущностей, агрегатов и доменных служб.
На основе результатов предыдущего шага идентифицируйте микрослужбы в своем приложении.
В этой статье рассматриваются первые два шага, которые в первую очередь касаются стратегического DDD. Статья "Тактический DDDD" охватывает шаг 3. В статье "Определение границ микрослужб" рассматривается шаг 4. DDD — это итеративный, текущий процесс, поэтому границы служб не остаются фиксированными. По мере развития приложения можно решить разделить службу на несколько небольших служб.
Примечание.
Эта статья не предназначена для демонстрации полного и исчерпывающего анализа предметной области. Пример намеренно краткий и сосредоточен на ключевых идеях. Для получения дополнительной информации о DDD прочитайте книгу Эрика Эванса Domain-Driven Design, которая впервые ввела этот термин. Еще одна хорошая справочная литература — Доменно-ориентированное проектирование Влада Хононова для практического, современного изложения темы.
Сценарий: доставка дронов
Fabrikam, Inc., запускает службу доставки дронов. Компания управляет парком дронов. Предприятия регистрируются в службе, и пользователи запрашивают беспилотный летательный аппарат для получения товаров для доставки. Когда клиент планирует получение, в внутренней системе назначается дрон и уведомляет пользователя о предполагаемом времени доставки. В то время как доставка выполняется, клиент отслеживает расположение беспилотных летательных аппаратов с непрерывным обновлением предполагаемого времени прибытия (ETA).
Этот сценарий включает сложный домен. Ключевыми бизнес-проблемами являются планирование беспилотных летательных аппаратов, отслеживание пакетов, управление учетными записями пользователей и хранение и анализ исторических данных. Fabrikam также стремится быстро выйти на рынок и проводить итерации, чтобы добавить новые функции и возможности. Приложение должно работать в масштабе облака и соответствовать высокой цели уровня обслуживания (SLO). Fabrikam также ожидает, что разные части системы должны иметь различные требования к хранилищу данных и операциям запросов. Эти соображения приводят Fabrikam к внедрению архитектуры микрослужб для приложения доставки дронов.
Анализ предметной области
Подход DDD помогает разрабатывать микрослужбы, чтобы каждая служба соответствовала функциональным бизнес-требованиям. Кроме того, вы можете избежать ограничений организации или выбора технологий, которые диктуют ваш дизайн.
Подсказка
Закон Конуэя отмечает, что системы, как правило, отражают коммуникационные структуры организаций, которые создают их. Если зеркальное отображение происходит пассивно, это может привести к архитектуре, которая отражает организационные диаграммы, а не бизнес-домены. DDD можно использовать в свою пользу, определив границы служб с помощью доменного анализа, а затем намеренно согласовывая владение командой с этими границами. Этот упреждающий подход гарантирует, что структура вашей команды поддерживает архитектуру, а не конфликтует с ней.
Если одна команда должна иметь несколько несвязанных контекстов, или один ограниченный контекст требует координации между многими командами, пересматривайте границы или структуру команды.
Прежде чем писать любой код, вам потребуется высокоуровневое понимание системы, которую вы создаете. DDD моделирует бизнес-домен и создает модель домена. Модель предметной области является абстрактной моделью предметной области бизнеса. Он систематизирует и упорядочивает знания в области и устанавливает общий язык для разработчиков и экспертов в области.
Начните с сопоставления всех бизнес-функций и соединений между ними. Эти усилия должны включать экспертов в области, архитекторов программного обеспечения и других заинтересованных лиц. Вам не нужно следовать определенному формальному методу. Например, можно нарисовать схему или использовать доску. Один структурированный подход включает в себя шторм событий. Независимо от того, используете ли вы event storming или менее формальный подход, цель заключается в создании общего понимания области, прежде чем выбрать технологии.
По мере заполнения схемы можно начать определять дискретные поддомены. Найдите следующие шаблоны:
Функции, которые тесно связаны
Функции, которые являются ключевыми для бизнеса и функций, которые предоставляют вспомогательные службы
Граф зависимостей между функциями
На этом начальном этапе не сосредоточьтесь на технологиях или деталях реализации. Но следует определить, где приложение должно интегрироваться с внешними системами, такими как управление отношениями клиентов, обработка платежей или системы выставления счетов.
Пример: приложение доставки дронов
После первоначального анализа домена команда Fabrikam создает грубый эскиз, который изображает домен доставки дронов.
Доставка отображается в центре схемы, так как она является основной для бизнеса. Все остальное на схеме существует для поддержки этой функции.
Управление дронами также является основным для бизнеса. Функциональные возможности, тесно связанные с управлением дронами, включают восстановление дронов и использование прогнозного анализа для прогнозирования необходимости обслуживания и обслуживания беспилотных летательных аппаратов.
Анализ ETA предоставляет оценки времени для погрузки и доставки.
Сторонний транспорт позволяет приложению планировать альтернативные методы транспортировки, если пакет не может быть доставлен полностью беспилотным летательным аппаратом.
Общий доступ к дронам — это возможное расширение основного бизнеса. Компания может иметь избыточные мощности беспилотных летательных аппаратов в течение определенных часов и может арендовывать бездействующиеся беспилотные летательные аппараты. Первоначальный выпуск не включает эту функцию.
Видеослежка является еще одной областью, которую компания может расширить позже.
Учетные записи пользователей, выставление счетов и центр обработки вызовов — это поддомены, поддерживающие основной бизнес.
DDD классифицирует поддомены в три категории, и эта классификация помогает определить, где инвестировать наиболее важные усилия по проектированию:
Основные поддомены обеспечивают конкурентное преимущество. Доставка и управление дронами формируют основные поддомены для Fabrikam, потому что они определяют бизнес. Для этих поддоменов требуется подробное моделирование и существенные инвестиции команды.
Поддержка поддоменов держит бизнес в рабочем состоянии, но не отличается от конкурентов. Выставление счетов попадает в эту категорию. Он требует пользовательской разработки, но не служит источником конкурентных преимуществ.
Универсальные поддомены представляют проблемы, которые уже решены в отрасли. Учетные записи пользователей и центр обработки вызовов представляют собой универсальные поддомены, которые Fabrikam может использовать с помощью существующих стандартных или предварительно созданных решений вместо разработанных на заказ систем.
На этом этапе в этом процессе Fabrikam не принял никаких решений о реализации или технологиях. Некоторые подсистемы могут включать внешние системы программного обеспечения или службы, отличные от Майкрософт. Но приложение должно взаимодействовать с этими системами и службами, поэтому Fabrikam включает их в модель домена.
Примечание.
Если приложение зависит от внешней системы, схема данных или API внешней системы может просочиться в приложение. Эта утечка может скомпрометировать архитектурную конструкцию. Это особенно распространено в устаревших системах, которые не соответствуют современным рекомендациям и могут использовать свертанные схемы данных или устаревшие API. В этих случаях необходимо установить четко определенную границу между внешней системой и приложением. Рекомендуется использовать шаблон Strangler Fig или шаблон уровня защиты от коррупции , чтобы применить эту границу.
Определение ограниченных контекстов
Модель домена включает представления реальных сущностей, таких как пользователи, беспилотные летательные аппараты, пакеты и другие сущности. Но это не означает, что каждая часть системы должна использовать одинаковые представления для одних и того же сущностей.
Например, подсистемы, обрабатывающие ремонт дронов и прогнозный анализ, должны представлять множество физических характеристик беспилотных летательных аппаратов, таких как их история обслуживания, пробег, возраст, номер модели и характеристики производительности. Но когда приходит время запланировать доставку, эти детали становятся неуместными. Подсистема планирования должна только знать, доступен ли дрон, и ETA для сбора и доставки.
Создание одной модели для обеих подсистем создает ненужную сложность. Модель также становится труднее развиваться с течением времени, так как изменения должны удовлетворять нескольким командам, работающим над отдельными подсистемами. В результате лучше разработать отдельные модели, представляющие одну и ту же сущность реального мира (в данном случае беспилотный летательный аппарат) в двух разных контекстах. Каждая модель включает только те функции и атрибуты, которые относятся к его контексту.
Здесь применяется концепция DDD для ограничивающих контекстов . Ограничивающий контекст определяет границу в домене, где применяется определенная модель домена. Fabrikam может группировать функциональные возможности на основе того, совместно ли разные функции используют одну и ту же модель домена.
Ограниченные контексты не обязательно изолированы друг от друга. На предыдущей схеме сплошные линии, соединяющие ограничивающие контексты, представляют места, где взаимодействуют два привязанных контекста. Например, доставка зависит от учетных записей пользователей для получения сведений о клиентах и управлении дронами для планирования беспилотных летательных аппаратов из флота.
Fabrikam определяет эти взаимодействия и создает карту контекста , которая документирует связи между ограничивающими контекстами. Карта контекста выделяет точки интеграции и помогает командам уточнить обязанности. Эванс и последующие специалисты DDDD описывают несколько шаблонов отношений:
Поставщик клиента: один контекст (вышестоящий) предоставляет данные или службы, от которые зависит другой контекст (подчиненный). Команды согласовывают контракт между ними.
Открытая служба узлов и Опубликованный язык: вышестоящий контекст предоставляет хорошо определенный API (Открытая служба узлов), описанный в общем формате (Опубликованный язык), который использует подчиненные контексты.
Уровень борьбы с коррупцией: нижестоящей команде создается уровень перевода для защиты модели от изменений вышестоящей модели.
Separate Ways. Два контекста не имеют интеграции. Каждый контекст развивается независимо.
В архитектуре микрослужб open Host Service и Published Language особенно важны, так как микрослужбы взаимодействуют с помощью хорошо определенных API. В статье API конструктора микрослужб описывается, как использовать спецификацию OpenAPI для определения описания интерфейсов REST API, выраженных в формате JSON или YAML.
Для остальной части этого путешествия мы сосредоточимся на ограниченном контексте доставки.
Следующий шаг
После завершения анализа домена примените тактическое DDD для определения моделей домена более точно.