Шаблон источника событий: почему я не должен хранить текущее состояние?

Question

Я изучаю шаблон источника событий. Я не могу понять его.

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

Будь это банковский счет. Для того, чтобы вернуться к моему клиенту ее текущее состояние счета я должен:

1. Extract все события, связанные с (возможно, есть тысячи событий в БД)
2. Compute количество свободных денег на тот момент.

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

Answer 1

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

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

Другая часть уравнения состоит в том, что ES дополняет шаблон CQRS - Command Query Responsibility Segregation, который отделяет модели чтения и записи (предыдущая ссылка не совсем корректна, IMO, вы можете посмотреть на this one). Затем выполняемые команды или события домена используются для постоянного обновления модели чтения, которая на самом деле является денормализованным представлением текущего состояния. Поэтому для команд вы будете создавать объекты домена из событий (ES) и действовать на них, тогда как для запросов вы будете обходить хранилище событий и извлекать данные непосредственно из модели чтения, которая может быть реляционной базой данных, базой данных документа или чем-то еще, которая оптимизирована для ваших сценариев чтения.

Если у вас есть приложение для чтения в основном, чем производительность командной стороны, которая реализована с помощью ES, возможно, это не так важно.

Преимущества ES не входят в сферу применения этого вопроса, и вы можете найти довольно много информации в Интернете (особенно Грег Янг и Уди Дахан). Я лично немного скептически отношусь к этому и считаю, что это имеет смысл, если вы работаете с долгосрочными бизнес-сценариями.