Menu
Presumably we could resurrect state by applying the same set of commands, so why not simply store commands rather than events?
363
Both are messages. They convey specific information; a command about the intent to do something, or an event about the fact that happened.
Instead of storing just the current state of the data in a domain, use an append-only store to record the full series of actions taken on that data. The store acts as the system of record and can be used to materialize the domain objects.
CQRS is implemented by a separation of responsibilities between commands and queries, and event sourcing is implemented by using the sequence of events to track changes in data.
Event sourcing is a powerful pattern and brings a lot of benefits to an application architecture if used appropriately: Makes write operations much faster as there is no read, update, and write required; write is merely appending an event to a log.
Events, communicate "this happened in our system". Events occur when a command has been accepted and processed. No one can reject or change the fact that it happened. It's the only authoritative source of changes in the system
Commands are just a way for a part of the system (like a UI) to tell the component in charge of making changes to the system (the "command handler") what it wants done. However, the command handler can choose not to process the command for various reasons. The UI could have stale information and processing the command wouldn't make business sense or the user could have not had the privileges to perform that action. Either way, the command is really just a request & have no bearing on the state of a system
.
80
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
