-1

I'm still learning event sourcing i dont undestand something. When i get a command to change object, do I first recreate that object from event store than change it and save event, or should i have separate table that holds last state? What is practice here?

milandjukic88
  • 1,065
  • 3
  • 13
  • 30
  • Please take the [tour] to learn how Stack Overflow works and read [ask] on how to improve the quality of your question. Then check the [help/on-topic] to see which questions are on-topic on this site. Please show your attempts you have tried and the problems/error messages you get from your attempts. – Progman Dec 05 '21 at 14:49
  • It's an implementation detail. ES asserts that the source of truth (and aggregate state) is the series of events. Using CQRS, or having commands as a way to intake write requests, you would take the command and the current state and make a decision on whether or not to commit the event. How you gather this state depends on the implementation: either replay all relevant events, or have some snapshotting mechanism as an optimization. – MasterAM Dec 05 '21 at 14:55

1 Answers1

3

I'm still learning event sourcing i don't understand something. When i get a command to change object, do I first recreate that object from event store than change it and save event, or should i have separate table that holds last state? What is practice here?

The first rule of optimization: Don't.

For handling commands, all of the information that you need to have is stored in your event history; simply loading the history and recomputing any state you need will get the job done.

In the case where you need low latency in your command handler, AND recomputing the state you need from the event history is too slow to meet your service level targets, then you might look into saving a "snapshot", and using that to speed up the load of your data.

Current consensus is that snapshots should be saved separately from the event history (ie: a snapshot is not another kind of event), as though the snapshot were another "read model".

VoiceOfUnreason
  • 52,766
  • 5
  • 49
  • 91