CQRS и Event Sourcing — читайте свои собственные события

В настоящее время я реализую архитектуру, управляемую событиями, и у меня есть служба для команды (часть записи) и другая служба для запроса (часть чтения).

Что я делаю прямо сейчас.

  1. Принять команду в CommandService
  2. Сохранение события и публикация события на шине событий
  3. ReadService прослушивает эти события и обновляет модели чтения.

Это звучит хорошо, если вы слушаете свои собственные события. Допустим, я слушаю внешнее событие от CommandService.

  1. Прослушать событие
  2. Обработать команду для этого события
  3. Сохраните событие, сгенерированное вашим доменом, в хранилище событий и опубликуйте это событие в шине событий.
  4. ReadService прослушивает эти события и обновляет модели чтения.

При таком подходе я вижу двойную задержку для обновления моих моделей чтения. Первая задержка -> время CommandService извлекает событие 2-я задержка -> время ReadService извлекает событие, сгенерированное из CommandService.

Я думаю, что если я обновлю свой ReadService для прослушивания хранилища событий CommandService напрямую без необходимости в шине событий, то я смогу уменьшить одну из этих задержек.

Что вы думаете?


cqrs event-sourcing event-driven-design
person Ahmed Alaa El-Din    schedule 25.10.2019    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Некоторое время назад мы делали что-то подобное. В принципе, у нас было

  1. Служба, реализующая шаблон диспетчера процессов и выполняющая некоторую логику координации между несколькими службами с помощью EventSourcing и Saga. Каждое событие, хранящееся в базе данных, содержит EventPayload, сериализованный в формате Avro, с состоянием процесса на момент возникновения события. Эта полезная нагрузка содержит все состояние, а не только различия, поэтому мы обновляли эту полезную нагрузку во время обработки.
  2. Мы использовали коннектор источника Kafka Connect JDBC для чтения из EventStore, и в основном, как только новое событие было опубликовано в EventStore, коннектор считывал событие и публиковал его в Kafka (Kafka использовалась как EventBus).
  3. Модель чтения, которая была помещена в другую службу, была обновлена ​​через Kafka (здесь есть два подхода: с помощью Kafka Connect JDBC Sink Connector или с использованием Kafka Consumer и выполнением транзакционных обновлений от Consumer).

Я надеюсь, что это поможет вам!

person Dina Bogdan    schedule 31.10.2019

arrow_upward
1
arrow_downward

Я думаю, что если я обновлю свой ReadService для прослушивания хранилища событий CommandService напрямую без необходимости в шине событий, то я смогу уменьшить одну из этих задержек.

Да, вы уменьшите задержку, но вы создадите связь между двумя службами, это не обязательно плохо, но если две службы разделены (используя шину), вы можете масштабировать каждую из них независимо.

Кроме того, если вы использовали управляемую шину, такую ​​​​как RabbitMQ, вы выиграете от подтверждения сообщения, нескольких типов доставки сообщений и очередей и т. д.

person adnanmuttaleb    schedule 31.10.2019