messages in our system can typically be broken down into three categories commands queries and events let's look at these in detail commands are a request to change the state of the system for example adding a user or creating a vehicle is a request to change the state when they are sent they can either be accepted or rejected because it may be important to know whether the command was successful or not they're often handled synchronously you send a command and you wait to see if it was accepted
queries on the other hand are a request for information about the state of the system if you want to know the details of a user or vehicle those would be queries designed properly a query should never change the state of the system they should be implemented in a read-only fashion like commands you often send a query and then wait for a response they're often handled synchronously in this course we're mostly concerned with events events record the changes to the system each time the state chang
es such as when we add a user we record an event they always represent something that happened in the past and are therefore expressed as past tense user added or vehicle created for example because events have already occurred it's rarely necessary to handle them synchronously they are usually broadcast to the system in a fire and forget manner they will be handled downstream when it's most convenient rather than immediately remember events represent the history of the system and we shouldn't t
amper with them they should always be immutable we tend to think about systems in terms of commands and queries we issue commands to change the state we issue queries to access that state we often don't think too much about what the impact of those state changes might be this is where events come in thinking in terms of events might be unfamiliar but it's also very powerful when we begin to build systems of events it opens a lot of doors their asynchronous nature makes them easier to distribute
and scale plus rather than coupling two systems together one system can emit events without worrying about who consumes them and then another system can consume the events without caring about who emitted them the two systems are bound only to the contract of the event this loose coupling makes it easier to build new systems off of those events it also makes it easier to evolve the old systems when necessary and it makes those systems more resilient to failures you
Comments