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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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