Можно ли удалить доменные события?

Question

Чтобы обеспечить согласованность обработки событий домена, я хочу сохранить события домена в базе данных при сохранении AggregateRoot.позже отреагируем на них, используя обработчик событий, например, скажем, я хочу отправить их на шину событий в качестве событий интеграции. Интересно, разрешено ли удалять событие из базы данных после его передачи через шину?Таким образом, события больше никогда не будут загружаться с корнем AggregateRoot.

Answer 1

Доменные события - это вещи, которые произошли в прошлом.Вы не можете удалить прошлое, если вы не Martin McFly:)

События домена не должны быть удалены из хранилища событий.Если вы хотите узнать, обрабатывали ли вы это ранее, вы можете добавить флаг, чтобы узнать это.

ОБНОВЛЕНИЕ ==> ОПИСАНИЕ ПРОЦЕССА УПРАВЛЕНИЯ СОБЫТИЯМИ

Я следуюподход IDDD (Красная книга Вона Вернона, см. рисунок на стр. 287) следующим образом:

1) Совокупность публикует событие локально для BC (облегченный издатель).

2)В BC легкий подписчик хранит все события, опубликованные BC, в «хранилище событий» (которое представляет собой таблицу в той же базе данных BC).

3) Пакетный процесс (рабочий) читаетхранить события и публиковать события в очереди сообщений (или, как вы говорите, в шине событий).

4) Другие BC, заинтересованные в событии (или даже в том же BC), подписываются на очередь сообщений (или событие).шина) для прослушивания и реагирования на событие.

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

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

Answer 2

Интересно, разрешено ли реактору удалять событие из БД после реакции.

Возможно, вы захотите просмотреть Надежный обмен сообщениями без распределенных транзакций , Udi Dahan;также статья Пэта Хелланда Life Beyond Distributed Transactions .

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

В системе, где журнал событий домена - это просто журнал сообщений, которые должны быть переданы другим «партнерам»: по сути, события домена - это сообщения, которые описывают информацию, которая будет скопирована из одной части.системы в другую.Поэтому, когда мы получаем подтверждение того, что сообщение было успешно скопировано, мы можем удалить копию, хранящуюся «здесь».

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

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

Вы можете иметь возможность обрабатывать запись событий домена как кеш- если партнер не завершил работу с сообщением в течение 7 дней с момента его доступности, то, возможно, доставка сообщения не самая большая проблема в системе.

Сколько девяток гарантии доставки делаюттебе нужно?