# What do you mean by “Event-Driven”? Martin Fowler 2017 https://perma.cc/FTY6-EJUL > The biggest outcome of the summit was recognizing that when people talk about “events”, they actually mean some quite different things. So we spent a lot of time trying to tease out what some useful patterns might be. > Furthermore we have to beware that all these patterns are good in the right place and bad when put on the wrong terrain. \- Martin Fowler ## Event Notification - Sending event messages to notify of a change in domain to another system - Response not required by source system - Event does not need to carry much data - Identifier - Minimal information that something that has changed and/or link to query sender for more information - Low level of coupling - There should be separation between the logic flow that sends the event and the logic flow that responds to the event - This separation can be broken which is problematic - e.g. Event is used as a passive-aggressive command, command should be used when the expectation is the receiver should carry out an action - Not explicitly defined in code - Often only way to identify is via monitoring a live system - Hard to debug and modify ## Event-Carried State Transfer - Update clients in a way that means they don't need to contact the source system to do further work - e.g. Event containing details of customer update is sent containing details of the data that is changed. The recipient can update its own copy of customer data - Advantages - Latency is reduced since the receiving system does not have to make a remote call to access customer data - Resiliency is improved as the recipient system can still function if the sender subsequently becomes unavailable - Disadvantages - More data is moved around and there are copies of the same data - Inconsistencies are possible - Higher level of complexity as the receiver has to maintain the state ## Event-Sourcing - When we make a change a system we record the change as an event which allows us to rebuilt the system state by reprocessing the events at any time in the future - Event store is the principal source of truth - e.g Version-control system where the log of all the commits are the events and the working copy is the current system state - Not all parts of an event-sourced systems need to be able to work directly against the event store, a useful working copy may be suitable - There should be a clear separation between the domain processing components and the components required to derive a working copy from the event store - Snapshots are useful so that we do not have to process all the events every time you need a working copy - Advantages - Strong audit capability - Possible to recreate historic states - Helpful if you want to re-create a production bug for debugging in a different environment - Disadvantages - Replaying events is problematic when there are dependencies on external systems - Handling schema changes of events over time - Complexity - Although this is probable if there is poor separation of concerns between components deriving a working copy and the domain processing components ## Command Query Responsibility Segregation (CQRS) CQRS is architectural pattern not an event pattern. It was discussed as it commonly combined with event patterns above. It is where the domain is split into two: 1. Command (Write) 2. Query (Read)