Как выглядят данные при использовании Event Sourcing?

Question

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

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

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

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

Другая интерпретация, которую я имею, заключается в том, что каждое событие хранит УКАЗАННУЮ информацию о том, что было изменено в документе. Например, когда состояние транспортного средства изменяется с «На дороге» на «Доступно», запускается событие, специально предназначенное для изменения состояния транспортного средства. Допустим, он называется VehicleStatusUpdatedEvent и содержит идентификационный номер транспортного средства, новый статус и метку времени для этого события. Таким образом, это событие сохраняется и публикуется в очереди сообщений. При получении из очереди соответствующие изменения вносятся в текущую версию документа. Я могу понять это, но я думаю, что у меня все еще есть некоторые заблуждения здесь. Насколько я понимаю, источник событий позволяет нам получать снимок данных при каждом изменении, поэтому мы можем знать, как он выглядит в любой момент. То, что я только что описал, будет вести журнал изменений, но при этом будет иметь только одну версию файла, так как события содержат только отдельные части всего файла.

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

Answer 1

Текущая нереляционная структура для модели данных такова, что каждый документ представляет транспортное средство

Хорошо, давайте начнем с этого.

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

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

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

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

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

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

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

То есть, когда вы ссылаетесь на старую сборку, вы восстанавливаете документ, используя события, верно?

Да, именно так.

Значит, документ "текущего статуса" все еще существует или это считается плохой практикой?

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

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

На этом этапе разработчики обычно либо решают, что «последняя версия» является достаточно хорошей, и в этом случае они создают в конечном итоге согласованные представления документов за пределами границы транзакции ... ИЛИ они решают, что текущая версия важна, и обращаются к хранилищу. решения, поддерживающие сохранение текущей версии в той же транзакции, что и события (например, использование СУБД).

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

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

Грубо говоря, у вас где-то есть функция, похожая на

document-with-meta-data = projection(event-history-with-metadata)