Соответствует ли эта схема микросервисам, DDD с источником событий

Question

1. Должен ли источник событий находиться в конце процесса и должны ли быть обработчики событий?
2. , при следовании источнику событий я знаю, что в любое время мы можем получить состояние приложения из событий, но мы должны сохранить это состояние в базе данных, а?

Answer 1

1. События генерируются после выполнения логина домена c (некоторая операция была выполнена над объектом / объектом домена). Сначала событие сохраняется в магазине, а затем публикуется на шине, и другие потребители (микросервисы, обработчики событий из вашей диаграммы) могут подписаться на него. Persist и publi sh события должны быть похожи на транзакцию.
2. Каждый раз, когда необходимо выполнить новую операцию над объектом домена, весь набор событий считывает из хранилища событий для этой сущности. Некоторые объекты могут иметь много событий и для оптимизации производительности используются так называемые Снимки состояний . В основном это состояние объекта домена после X событий. Снимки могут быть созданы каждые X событий. Они хранятся отдельно в хранилище событий, и обычно библиотеки источников событий позволяют настраивать моментальные снимки. Но это только для повышения производительности.

Я быстро создал диаграмму, чтобы показать, что обычно это происходит внутри Обработчик команд

Answer 2

Похоже, вы хотите использовать шаблон поиска событий CQRS +.

Вот несколько примеров:

• https://dzone.com/articles/microservices-with-cqrs-and-event-sourcing
• https://danielwhittaker.me/2020/02/20/cqrs-step-step-guide-flow-typical-application/

По ссылкам выше вы можете исправить свою архитектуру, и я думаю, что это отвечает на первый вопрос.

Что касается второго вопрос, у вас должно быть внешнее хранилище событий.

Эти два шаблона хорошо описаны в этой книге .