Domain-Driven Design (DDD)
Вспомним масштабирующуюся транспортную компанию CityTransit из прошлого урока. Бизнес растёт, а системы становятся более сложными и неуправляемыми. Без чёткого разделения на домены и контексты разработчики будут теряться в огромном количестве взаимосвязанных функций и данных. Это приводит к увеличению времени разработки, снижению качества кода и трудностям в поддержке системы.
Вы уже представляете, как решить эту проблему и какую роль здесь играет подход Domain-Driven Design (DDD). В этом уроке вы узнаете немного больше о DDD: рассмотрите уровни проектирования, основные понятия и их значение в проектировании микросервисов.
На примере компании CityTransit мы разберём процесс выделения доменов и контекстов, а также их реализацию в виде микросервисов.
Методология Domain-Driven Design (DDD)
Основоположник DDD Эрик Эванс представил новую концепцию в своей книге «Domain-Driven Design: Tackling Complexity in the Heart of Software» в 2003 году. Его подход заключался в том, что разработка программного обеспечения фокусируется на глубоком понимании бизнес-домена и его модели.
Микросервисы и DDD прекрасно сочетаются друг с другом, поскольку оба подхода подчёркивают важность разделения системы на независимые компоненты с чёткими границами.
Цель микросервисной архитектуры — разбить приложение на множество автономных сервисов, каждый из которых выполняет свою функцию. А DDD предлагает методологию, чтобы определить, какие именно микросервисы нужны и как они должны взаимодействовать.
Основные понятия DDD
Домен — это область знаний или деятельности, которая представляет собой основную часть работы компании. В контексте DDD домен охватывает все понятия, связанные с данной областью, и описывает её поведение и правила.
Поддомен — это логически выделенная часть домена, которая выполняет определённую функцию или решает конкретную задачу. В домене может быть несколько поддоменов, каждый из которых важен для общей картины.
Контекст — это область, внутри которой определённые термины и правила имеют чёткое значение. В DDD контексты помогают избежать путаницы, определяя границы использования понятий.
Задание 1
Соотнесите область бизнеса с соответствующим компонентом в методологии DDD.
Часть системы, отвечающая за расписание автобусов в транспортной компании
Поддомен
Поддомен отражает определённую функцию или конкретную задачу.
Область компании, ответственная за управление транспортом, включая автобусы, трамваи и метро
Домен
Домен — наиболее крупная сущность подхода, отражающая области работы компании.
Граница, внутри которой термины «расписание» и «маршрут» имеют чёткие и согласованные значения
Контекст
Контекст очерчивает область применения и значение терминов.
Domain-Driven Design разделяется на два уровня проектирования — стратегическое и тактическое. Понимание этих уровней помогает более эффективно организовать разработку и управление системой, облегчить взаимодействие между командами и улучшить масштабируемость и гибкость архитектуры. Так можно избежать проблем с путаницей в терминологии и ролях, сложностей в координации между командами, недостаточной масштабируемости и затруднений в управлении сложными системами.
Стратегическое проектирование
На этом уровне определяется общая структура системы и взаимодействие между различными частями домена. Основная задача — разделить систему на поддомены и очертить границы контекстов.
Основные элементы
- Bounded Context: определяет границы, в пределах которых терминология и правила имеют чёткое значение.
- Context Map: диаграмма, показывающая взаимодействие между различными контекстами.
В компании CityTransit стратегическое проектирование поможет определить основные домены и поддомены системы, а затем выделить контексты.
- Домен: управление транспортом
- поддомен управления расписанием
- контекст: планирование расписания
- контекст: публикация расписания
- поддомен управления расписанием
- поддомен управления платежами
- контекст: обработка транзакций
- контекст: ведение журнала транзакций
- поддомен обработки платежей
- поддомен управления пользователями
- поддомен отслеживания транспорта
- поддомен отчётности и аналитики
Тактическое проектирование
На этом уровне определяются детали реализации внутри каждого контекста. Основная задача — создать модель, которая точно отражает бизнес-логику и поведение домена.
Основные элементы:
- Entities: объекты, которые имеют уникальный идентификатор и состояние, изменяющееся со временем.
- Value Objects: объекты, которые не имеют уникального идентификатора и полностью определяются своими атрибутами.
- Aggregates: группы связанных сущностей и объектов-значений, которые обрабатываются как единое целое.
- Repositories: интерфейсы для доступа к агрегатам из хранилища данных.
- Services: операции, которые не относятся к какой-либо сущности, но важны для домена.
Например, на этапе тактического проектирования компания CityTransit может детализировать каждый из контекстов, определяя сущности, объекты-значения, агрегаты, репозитории и сервисы.
Микросервис управления расписанием
- Контекст планирования расписания:
- сущности: расписание, маршрут;
- объекты-значения: время отправления, время прибытия;
- агрегаты: расписание;
- репозитории: репозиторий расписания;
- сервисы: сервис планирования расписания.
Микросервис обработки платежей
- Контекст обработки транзакций:
- сущности: транзакция, платёж;
- объекты-значения: сумма, валюта;
- агрегаты: транзакция;
- репозитории: репозиторий транзакций;
- сервисы: сервис обработки транзакций.
Стратегическое проектирование позволяет определить высокоуровневую структуру системы, а тактическое проектирование — детализировать каждый контекст, обеспечивая реализацию бизнес-логики.
Процесс выделения доменов и контекстов
Правильное выделение доменов и контекстов помогает структурировать систему так, чтобы она отражала реальную бизнес-логику и потребности организации. Рассмотрим шаги этого процесса и примеры из реальной жизни.
Шаг 1. Анализ бизнеса и требований
Первым шагом является глубокое понимание бизнес-процессов и требований. На этом этапе нужно пообщаться с бизнес-экспертами и собрать информацию о том, как работает компания, какие задачи она решает и какие проблемы возникают.
Задачи:
- Проведение интервью с ключевыми бизнес-экспертами.
- Сбор и анализ бизнес-требований и сценариев использования.
- Определение основных бизнес-целей и приоритетов.
В компании CityTransit команда разработчиков проводит серию встреч с менеджерами и сотрудниками, чтобы понять, как работает система продажи билетов, управление транспортом и мониторинг транспорта.
Шаг 2. Выделение доменов
На основе собранной информации определяется основной домен системы — та область, которая охватывает все аспекты, связанные с бизнес-логикой и правилами.
Задачи:
- Определение границ домена.
- Идентификация основных функций и процессов внутри домена.
- Документирование ключевых понятий и терминов, используемых в домене.
В CityTransit основными доменами могут быть управление транспортом, продажа билетов и мониторинг транспорта.
Шаг 3. Разделение на поддомены
Каждый домен может быть разбит на более мелкие логические части, называемые поддоменами. Поддомены фокусируются на конкретных функциях или задачах внутри основного домена.
Задачи:
- Идентификация поддоменов на основе функциональных требований.
- Определение взаимодействий между поддоменами.
- Документирование поддоменов и их границ.
В домене управления транспортом в CityTransit поддоменами могут быть: Управление расписанием. Управление маршрутами. Управление транспортными средствами.
Шаг 4. Определение контекстов
Контексты (Bounded Contexts) помогают избежать путаницы, определяя границы, в пределах которых термины и правила имеют чёткое значение. Каждый поддомен может содержать один или несколько контекстов.
Задачи:
- Определение границ контекстов внутри поддоменов.
- Создание контекстных карт (Context Maps) для визуализации взаимодействий.
- Документирование терминов и правил внутри каждого контекста.
В поддомене управления расписанием в CityTransit контекстами могут быть контекст планирования расписания (с терминами «время отправления», «время прибытия»). Контекст публикации расписания (с терминами «публикация», «обновление расписания»).
Шаг 5. Создание контекстных карт (Context Maps)
Контекстные карты визуализируют взаимодействие между различными контекстами. Они помогают понять, как данные и команды перемещаются между контекстами, и выявить потенциальные проблемы или зависимости.
Задачи:
- Создание диаграмм, отображающих контексты и их взаимодействия.
- Определение типов взаимодействий (например, интеграция, антипаттерны).
- Документирование зависимостей и договорённостей между контекстами.
В CityTransit контекстная карта может показать, как контекст планирования расписания взаимодействует с контекстом публикации расписания или как контексты продажи билетов и мониторинга транспорта зависят от контекста управления расписанием.
Шаг 6. Итеративное уточнение
Процесс выделения доменов и контекстов является итеративным. Если поступает новая информация или в бизнес-требования вносятся изменения, границы доменов и контекстов могут быть пересмотрены и уточнены.
Задачи:
- Регулярный пересмотр и обновление доменов и контекстов.
- Внедрение изменений на основе обратной связи от пользователей и команды.
- Обеспечение согласованности между всеми частями системы.
В CityTransit по мере развития системы и появления новых требований команда может пересматривать и уточнять границы поддоменов и контекстов, чтобы они оставались актуальными и эффективными.
Задание 2
Выберите правильную последовательность шагов и сопоставьте с ключевыми задачами.
Применение DDD в работе с микросервисами
На основе выделенных доменов, поддоменов и контекстов мы можем спроектировать соответствующие микросервисы. Рассмотрим, как это выглядит, на примере CityTransit.
- Управление транспортом: всё, что связано с планированием и управлением движением транспорта.
- Микросервис управления расписанием:
- Планирование расписания: микросервис, который отвечает за создание и изменение расписания.
- Публикация расписания: микросервис, который отвечает за распространение и обновление расписания для пользователей.
- Микросервис управления расписанием:
- Микросервис управления маршрутами:
- Управление маршрутами: микросервис, который управляет маршрутами транспортных средств и их оптимизацией.
- Микросервис обработки платежей:
- Обработка транзакций: микросервис, который отвечает за обработку платежей и интеграцию с платёжными системами.
- Ведение журнала транзакций: микросервис, который ведёт учёт всех транзакций и их состояния.
- Управление аккаунтами пользователей: микросервис, который отвечает за регистрацию, аутентификацию и управление данными пользователей.
- Микросервис отслеживания транспорта:
- Отслеживание местоположения: микросервис, который собирает и обрабатывает данные о местоположении транспортных средств.
- Аналитика состояния транспорта: микросервис, который анализирует данные о состоянии транспорта и генерирует отчёты.
Рассмотрим конкретный пример, как реализован микросервис обработки платежей в контексте CityTransit.
Микросервис обработки платежей
- Определение бизнес-требований:
- Обработка платежей за билеты.
- Поддержание различных способов оплаты (кредитные карты, электронные кошельки и так далее).
- Ведение журнала транзакций для отслеживания состояния платежей.
- Проектирование микросервиса:
- Контекст обработки транзакций:
- API для приёма платёжных данных.
- Логика интеграции с платёжными шлюзами.
- Обработка статусов платежей (успех, отказ, возврат).
- Контекст обработки транзакций:
- Контекст ведения журнала транзакций:
- Хранение информации обо всех транзакциях.
- API для получения данных о транзакциях для отчётности и аналитики.
- Реализация микросервиса:
- Разработка API для обработки транзакций.
- Интеграция с платёжными шлюзами.
- Реализация ведения журнала транзакций и предоставление данных для других сервисов (например, для микросервиса отчётности).
Задание 4
Компания FoodDelivery занимается доставкой еды из различных ресторанов. По описанию бизнес-области выделены домены и контексты, которые могут быть преобразованы в микросервисы. Соедините контексты с соответствующими доменами.
Задание 6
Сопоставьте границы контекстов DDD с границами микросервисов для компании FoodDelivery.
- Микросервис аналитики: Этот микросервис может быть полезен для анализа данных и генерации отчётов, но он не соответствует ни одному из описанных контекстов DDD для компании FoodDelivery.
- Микросервис уведомлений: Уведомления могут быть важной частью других систем, но в данном случае это не соответствует описанным контекстам DDD для компании FoodDelivery.
Правильное сопоставление контекстов DDD с границами микросервисов помогает структурировать и разделить ответственность в системе, улучшая масштабируемость и управляемость. Для компании FoodDelivery правильное определение микросервисов, таких как управление заказами и логистика доставки, позволяет эффективно обрабатывать заказы, управлять ресторанами и доставлять заказы клиентам.
Задание 7
Распределите предложенные сущности в правильные домены для компании CityTransit.
Итоги
Подход DDD подразумевает, что для проектирования микросервисной архитектуры совместно с бизнес-экспертами определяются области:
- домены, которые представляют собой основную часть работы компании.
- поддомены — выделенные части домена с определённой функцией или конкретной задачей.
- контексты — границы, очерчивающие правила и значения использования терминов.
DDD помогает спроектировать микросервисную архитектуру на основе потребностей и задач бизнеса. В процессе проектирования коммуникация между бизнесом и командой разработки играет важную роль, поэтому архитектурные решения нужно документировать и визуализировать. Для визуализации очень удобны диаграммы: они отображают устройство системы, помогают вовремя заметить узкие места и проблемы. А ещё упрощают коммуникацию для всех участников проекта.
В следующих уроках мы расскажем про инструменты для описания архитектуры и создания диаграмм — модель С4 и PlantUML.