Где хранить события в распределенной системе, которая использует источник событий?

Question

Учитывая, что у вас есть несколько систем, которые интегрированы по событиям, и все они используют источник событий. Где вы храните события?

В моем случае у меня есть три системы:

• Сайт, который представляет собой магазин
• Бэкэнд для Веб-сайта для управления клиентами, продуктами и т.д.
• Система бухгалтерского учета

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

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

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

Я думаю, что есть большая разница в системах, которые не используют источник событий на данный момент. Если вам нужно реализовать функцию в системе A, которая зависит от данных, которая недоступна в A, но в другой системе B, и вы сохраняете текущее состояние с помощью инструмента ORM, такого как NHibernate, вы можете просто импортировать эти данные из A в B Поскольку система, использующая источники событий, зависит от событий, чтобы добраться до ее текущего состояния, вам необходимо импортировать все события, которые вы пропустили в прошлом, но нужны сейчас.

Для меня есть несколько разных подходов к этой проблеме.

1. Каждая система сохраняет все публикуемые события. Это дает вам возможность при необходимости переиздавать события или импортировать их в другую систему.
2. Каждая система сохраняет все происходящие события, даже те, которые не нужно обрабатывать (пока).
3. Все события из всей системы хранятся в центральном журнале событий. Если вам нужно обработать событие, которое произошло в прошлом, но вы не подписались на него, вы можете импортировать его отсюда.

Как вы справляетесь с такой ситуацией? Где вы сохраняете свои события?

Редактировать

Спасибо, Рой Диктус, за ваш ответ. Я все еще не уверен, как справиться со следующей ситуацией:

На сайте публикуются события CustomerRegistered, CustomerPurchasedProduct и CustomerMarkedProductAsFavorite. В текущей версии бэкэнда клиенты должны отображаться, а их покупки должны отображаться. То, что клиент отметил как любимый, не интересует эта версия системы. Таким образом, бэкэнд подписывался только на CustomerRegistered и CustomerPurchasedProduct.

Теперь отдел маркетинга также хочет, чтобы информация о любимых продуктах отображалась на странице сведений о клиенте. Поскольку бэкэнд не подписывался на CustomerMarkedProductAsFavorite, эта информация недоступна в бэкенде. Где я могу получить эту информацию?

Answer 1

1. Каждая система хранит свои собственные события. Каждая система является своей собственной системой CQRS или, по крайней мере, своей собственной автономной службой, и поэтому отвечает за свои собственные данные.
2. Каждая система также публикует свое событие на служебной шине. Этот сервисный автобус определяет, где он сохраняет эти события. Обычно это система транзакционных очередей.
3. Каждая система подписывается на внешние события, которые она потребляет. Он не хранит эти входящие события, а только свои собственные события, которые вытекают из них. Когда он использует входящее событие, служебная шина знает, что может удалить событие из входящей очереди этой службы.

РЕДАКТИРОВАТЬ , чтобы ответить на ваш дополнительный вопрос:

Если другое приложение вдруг заинтересовалось дополнительной информацией, оно должно добавить слушателей к интересующим его событиям.

Кроме того, все источники этих событий могут затем воспроизводить эти события. Воспроизведение - это мощная функция управляемых событиями систем, которая учитывает такие сценарии. Таким образом, источники событий воспроизводят только выбранные события (скажем, все события CustomerMarkedItemAsFavorite за последние 6 месяцев). Системы, которые уже использовали эти события, должны распознавать, что воспроизводимые события являются «старыми» (т.е. уже обработаны), и игнорировать их.

Таким образом, любая подсистема, которая обновлена ​​для использования дополнительной информации из других подсистем, может получать эту информацию и получать все обновления в одной пакетной операции.

Answer 2

WRT ваше редактирование: действительно ли необходимо также получить доступ к историческим данным CustomerMarkedProductAsFavorite. Измените бэкэнд, чтобы подписаться на новые данные, и тогда у вас это будет вперед. Вы можете решить, как заполнить отсутствующие данные отдельной проблемой, если она вам действительно нужна.

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