to review:
- I've always stayed clear from (2) Event State Transfer because of the issues with not having idempotent behavior. Passing in state to your messages means you need to process them in order. That means you have to be careful about scaling horizontally.
- If a system uses Event Carried State Transfer, then it makes sense to define a Command as a request to change state.
- Commands are requests for something to happen. An Event is what has already happened. For example: a user might Command the system to save a file. The system might then generate an Event "the file was saved" or an Event "error saving file".
- Versioning in Eventsourcing is not brought in during design phase. This video has mention of this book -https://leanpub.com/esversioning
- An event represents a statement of fact, so it cannot fail, but a command is a request to make a perform a change, so it may be refused