Снимок как событие домена в источнике событий

Question

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

Мой вопрос заключается в том, должен ли я создавать конкретное событие для моментального снимка, поэтому что-то вроде «WarehouseStateSnapshotted» . В моем текущем прототипе состояние снимка сохраняется в дублирующемся коде, существующем в нескольких обработчиках команд. Я чувствую, что это не та область, с которой нужно обращаться Я бы предпочел отправить событие для моментального снимка на мою служебную шину, и обработчик событий сохранил бы состояние моментального снимка. Это может, однако, нарушить управляемый доменом шаблон событий, которые они сами. Есть ли у других событий, созданных для моментальных снимков?

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

Спасибо!

РЕДАКТИРОВАТЬ: Заголовок и - Этот комментарий , кажется, предлагает снимки, поскольку доменные события - неправильный подход.

EDIT2: Упрощенный вопрос - уместно ли вводить репозитории в обработчики команд?

Answer 1

Я немного баловался с источником событий, но я не эксперт. Мне не особенно нравится идея отдельного « stream », представляющего снимок. Это не большая часть потока, поскольку он хранит только последний снимок. В моем проекте Shuttle.Recall , который все еще находится в зачаточном состоянии, я сохраняю снимки как обычные события домена, но они специально помечаются как снимки, а последняя версия снимка сохраняется отдельно для загрузки, а затем События после этой версии применяются. Я нахожу некоторые преимущества в том, что вы можете добавить некоторые функции и к снимкам.

Когда вы используете снимки как чисто техническое улучшение производительности, это может не принести особой пользы вашему домену. Если моментальный снимок не принадлежит агрегату / домену, то как можно было бы увлажнить агрегат из моментального снимка?

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

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

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

Но, как я уже сказал ... Я все еще учусь:)

Answer 2

У меня вопрос, должен ли я создавать конкретное событие для моментального снимка, поэтому что-то вроде "WarehouseStateSnapshotted".

«Это зависит».

Ссылка, которую вы должны просмотреть для моментального снимка: CQRS Documents , автор Greg Young. Это относительно старый 2010 год, но он служит простым введением в концепцию моментальных снимков.

Нет ничего плохого в том, чтобы генерировать моментальные снимки асинхронно и сохранять их вне потока событий.

Вы можете использовать любой разумный триггер для процесса моментального снимка; вам не обязательно нужно событие в потоке. «Снимок каждые 100 событий» или «Снимок каждые 10 минут» или «Снимок, когда администратор нажимает кнопку моментального снимка» - все это жизнеспособно.

Некоторые домены имеют естественную частоту, когда сам домен может предложить снимок - подумайте «закрытие книг в финансовом году».

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

Answer 3

Позвольте мне сначала напасть на легкого. Логика моментальных снимков не относится к совокупности. Является ли и когда вы shapshot просто проблемой производительности и не относится к бизнес-правилам. Это помогает провести черту, представив сервер с бесконечными ресурсами. Если вам не нужно делать «вещь» на этой удивительной машине, «вещь» не входит в совокупность.

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