Доменные события¶
В контексте DDD доменное событие — это нечто, произошедшее с агрегатом. Обычно представляет изменение состояния.
Зачем публиковать события¶
Полезность публикации доменных событий в том, что другие стороны взаимодействия (пользователи, внешние приложения или другие компоненты приложения) заинтересованы в информации об изменениях в состоянии агрегата. Например:
- Обеспечение согласованности между сервисами с помощью повествований на основе хореографии
- Уведомление сервиса, который хранит реплику, об изменении в источнике данных
- Уведомление другого приложения через вебхук или брокер сообщений
- Уведомление другого компонента приложения, чтобы послать сообщение пользователю или обновить БД
- Рассылка пользователям уведомлений
- Мониторинг для проверки корректности поведения системы
- Анализ событий для моделирования поведения пользователя
Обогащение события¶
Обогащение события — добавление в объект события информации, необходимой потребителю. Например, агрегат Order может обогатить событие OrderCreated, добавив информацию о заказе.
Обогащение события упрощает потребителей, но несет риск снижения стабильности классов событий, а также усилит связность.
Определение доменных событий¶
Есть несколько стратегий для определения доменных событий. Часто сценарии, в которых необходимы уведомления, описываются в ТЗ. Например: “Если произойдет X, сделайте Y”. Такие формулировки указывают на существование доменного события.
Событийный штурм¶
Другой подход — Событийный штурм — формат собрания для обсуждения сложного домена, сосредоточенный вокруг событий. Имеет три этапа:
1. Интенсивное определение событий — специалистов в проблемной области просят определить доменные события.
2. Определение причин событий — специалистов в проблемной области просят определить причину каждого события, которая может быть одной из следующих
- действие пользователя (команда)
- внешняя система
- другое доменное событие
- истечение времени
3. Определение агрегатов. Специалистов в проблемной области просят определить агрегат, который потребляет каждую команду и генерирует соответствующее событие.
Генерация доменных событий¶
На концептуальном уровне доменные события публикуются агрегатами. Агрегат знает, когда меняется его состояние и, следовательно, какое событие нужно опубликовать. Агрегат модет обращаться непосредственно к API для обмена сообщениями, однако это приведет к переплетению инфраструктуры и бизнес-логики, что нежелательно.
Более подходящим подходом будет разделение ответственности между агрегатом и сервисом. Например, агрегат генерирует события при изменении своего состояния и возвращает их сервису. Сервис вызывает метод корня агрегата и затем публикует полученные в результате сообщения.
Другой вариант - агрегат накапливает события в своём корне, затем сервис их извлекает и публикует.
Публикация доменных событий¶
Публикация событий не отличается от публикации асинхронных сообщений. Чтобы события публиковались как часть транзакции, обновляющей агрегат в БД, применяем шаблон OUTBOX
Потребление доменных событий¶
Доменные события в виде сообщений попадают в брокер, где на них подписываются желающие.
Дата создания : 27 июля 2022 г.