Адриан Кокрофт (Adrian Cockcroft), ранее работавший в Netflix, определяет микросервисную архитектуру как сервис-ориентированную, состоящую из слабо связанных элементов с ограниченным контекстом.
Обобщенное определение микросервисной архитектуры (или микросервисов) звучит так: это стиль проектирования, который разбивает приложение на отдельные сервисы с разными функциями.
Более подходящим подходом будет разделение ответственности между агрегатом и сервисом (или эквивалентным классом), который к нему обращается. Сервисы могут использовать внедрение зависимостей для получения ссылки на API для обмена сообщениями, что позволяет им легко публиковать события. Агрегат генерирует события при изменении своего состояния и возвращает их сервису (последняя часть может быть реализована несколькими способами). Один из вариантов — включить в значение, возвращаемое методом агрегата, список событий
Недостаток этого подхода связан с тем, что агрегат не поддерживает внедрение зависимостей, из-за чего API для обмена сообщениями придется передавать в метод в виде аргумента. Это приведет к переплетению инфраструктуры и бизнес-логики, что крайне нежелательно.
На концептуальном уровне доменные события публикуются агрегатами. Агрегат знает, когда меняется его состояние и, следовательно, какое событие нужно опубликовать. Агрегат может обращаться непосредственно к API для обмена сообщениями
Событийный штурм — это формат собрания для обсуждения сложного домена, сосредоточенный вокруг событий. Специалисты в предметной области собираются в комнате с большой доской для рисования или рулоном бумаги, куда будут крепиться небольшие записки. Результатом этого процесса становится событийная доменная модель, состоящая из агрегатов и событий.
Есть несколько разных стратегий для определения доменных событий. Часто сценарии, в которых необходимы уведомления, описываются в требованиях к приложению. Требования могут быть сформулированы так: «Если произойдет X, сделайте Y».
