CQRS C#, Whats Цель репозитория EventSource для восстановления объекта, почему Cannt мы используем акктуальную базу данных для Resocnstituting объекта

Question

CQRS C#, Whats Цель репозитория EventSource для воссоздания объекта, почему мы не можем использовать фактическую базу данных для Восстановление объекта.

Answer 1

Почему мы не можем использовать фактическую базу данных для воссоздания объекта.

Вы можете. Шаблон CQRS и «event sourcing» - это две отдельные идеи.

CQRS и Event Sourcing, как правило, говорили в комбинации, потому что (а) они происходят совмещаются очень хорошо, и (б) Грег Янг, который первым сформулировал образец CQRS, также способствует использование источников событий/хранилищ событий по ряду причин.

Итак, если вы много читаете о CQRS, вы также, вероятно, прочтете множество аргументов в поддержку источников событий. Обратное также верно.

Но муфта не требуется. Если сохранение/получение снимков вашей модели записи лучше подходит для ваших текущих требований, чем сохранение/извлечение истории событий, то сделайте это. Лошади для курсов.

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

Как вы совершаете сделку между EventStore Repository и записью Model Repository?

Вы не.

Если вы хотите, чтобы книга записи (то есть источник, из которой модель записи воссоздает объект) была «реальной базой данных», схема истории событий также реализована в фактической базе данных, и вы пишете как в одной транзакции. См. Reliable Messaging without Distributed Transactions.

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

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

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