Timeline for Event sourcing, replaying and versioning
Current License: CC BY-SA 3.0
4 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 17, 2016 at 14:40 | comment | added | Antony Woods | I didn't accept this answer but I want to thank you for contribution as it was vital in amending my understanding. I chose rmayer06's answer just because it was more direct, rounded and more useful to some one just accessing this question for a quick answer. | |
| Feb 16, 2016 at 14:28 | comment | added | VoiceOfUnreason | Yes, that's right. Each change of state in your event sourced entity is represented by one or more events; to rehydrate, you replay all of those events in order. | |
| Feb 16, 2016 at 14:03 | comment | added | Antony Woods | Ok, so I think your advice is to worry less about restoring from commands and more about from events? For example, if I get a command along the lines of "add 10 beans" then I should subsequently issue and store an event which says "10 beans were added. new total: 40"? | |
| Feb 15, 2016 at 18:24 | history | answered | VoiceOfUnreason | CC BY-SA 3.0 |