Источники событий и перестроение логики

Я новичок в поиске событий, и я немного запутался в восстановлении объектов из потока событий.

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

Если у меня есть клиент Object Called.

Public class Customer
{
   public void Correctname(string firstName,string lastName)
    {
        CustomerNameChanged(new nameChangedEvent(firstName,lastName);
    }
}

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


cqrs event-sourcing domain-driven-design
person satish    schedule 28.05.2012    source источник
comment
Опасность пропуска событий из потока во время воспроизведения заключается в том, что вы делаете ПРЕДПОЛОЖЕНИЯ, которые верны только для текущей версии вашей объектной модели. Вещи имеют свойство меняться...   -  person Yves Reynhout    schedule 25.06.2012

Ответы (2)


arrow_upward
3
arrow_downward

Вы должны повторно применить оба события к объекту Customer. Поскольку вы применяете их в хронологическом порядке, объект Customer будет находиться в правильном текущем состоянии. Если вас беспокоит количество применяемых событий, которые больше не отражают текущее состояние, вам следует просмотреть Снимки

person David Masters    schedule 28.05.2012
comment
на самом деле при перестроении объекта IMHO второе событие, на мой взгляд, бесполезно (или я что-то упускаю), так почему мы не можем получить уникальные события сверху и повторно применить их. Остальные события нужны только в том случае, если нам нужно привести объект в текущее состояние в определенное время. - person satish; 28.05.2012
comment
Можно сказать, что вы получаете только самое последнее событие «CustomerNameChanged». Это может сработать для изменения имени, которое с точки зрения доменной логики бессмысленно, но этот подход не сработает для такого события, как «AccountBalanceIncreased». Здесь требуются предыдущие события, чтобы объект вернулся в свое текущее состояние; так будет в большинстве случаев. Кроме того, если вы попытаетесь отфильтровать самые последние события, вам придется добавить логику запроса для каждого события объекта, что было бы серьезной проблемой. Вам гораздо лучше делать снимки, если вас беспокоит производительность. - person David Masters; 28.05.2012
comment
Спасибо @david. Это имеет полный смысл. Но для увеличения баланса учетной записи, как будет выглядеть снимок, будет ли он рассчитывать сумму до времени и сохраняться в виде снимка - person satish; 28.05.2012
comment
С балансом учетной записи объект будет иметь свойство «Баланс», которое будет увеличиваться каждый раз, когда применяется событие AccountBalanceIncreased. После X количества событий вы можете создать объект Snapshot, который является просто объектом данных, который представляет текущее состояние всего объекта, и скопировать свойство Balance из объекта в объект моментального снимка и сохранить его в БД. Идея заключается в том, что когда вы приходите к выборке объекта, вы сначала ищете последний снимок, а затем применяете все события, которые произошли после этого снимка. Полезно, если ваши объекты имеют длительное время жизни с большим количеством событий. - person David Masters; 28.05.2012

arrow_upward
1
arrow_downward

При перестроении объекта вы обрабатываете весь поток событий для этого объекта. С точки зрения производительности это обычно не проблема, даже для большого количества событий. Этого можно избежать, используя прокручивающиеся снимки.

С помощью снимков вы сохраняете состояние вашего объекта в определенной точке потока событий. Пересборка — это просто загрузка этого моментального снимка + событий, которые произошли после создания моментального снимка.

person Martijn van den Broek    schedule 28.05.2012