Resource
https://martinfowler.com/articles/201701-event-driven.html
Digest
Abstraction
Event Notification | Event-Carried State Transfer | Event Source | CQRS | |
---|---|---|---|---|
Key Usage |
|
|
|
|
Event Notification
Model :
- Listener : Register as Listener of Source;
- Source : State Change
- Source : Compose Event Message
- Source : Notify Listeners
- Listener : Decompose Event Message
- Listenter (Optional) : Fetch More Information from Source with IDs in Event Message
- Listener : Process
Note :
- Message Contains ID Only
- Listner need to fetch the CHANGES/STATE from the Soruce, if needed.
- A key element of event notification is that the source system doesn't really care much about the response. Often it doesn't expect any answer at all, or if there is a response that the source does care about, it's indirect.
- An event need not carry much data on it, often just some id information and a link back to the sender that can be queried for more information. The receiver knows something has changed, may get some minimal information on the nature of the change, but then issues a request back to the sender to decide what to do next.
Pros :
- Decouple Source and Listener
- STATE is maintained in one place
- Easy to implement
Cons :
- If there really is a logical flow that runs over various event notifications. The problem is that it can be hard to see such a flow as it's not explicit in any program text.
Event Carried-State Transfer
Model :
- Listener : Register as Listener of Source;
- Source : State Change
- Source : Compose Event Message (ID + New State)
- Source : Notify Listeners
- Listener : Decompose Event Message
- Listener : Get the New State from decomposed message
- Listener : Process
Note :
- This pattern shows up when you want to update clients of a system in such a way that they don't need to contact the source system in order to do further work.
- Kinda of a redudency
Pros :
- The recipient (Listener) systems can function if the customer system is becomes unavailable.
- Reduced latency, as there's no remote call required to access Source.
- No need to worry about load on the Source to satisfy queries from all the consumer (Listener) systems.
Cons :
- It does involve more complexity on the receiver (Listener), since it has to sort out maintaining all the STATE, when it's usually easier just to call the sender (Source) for more information when needed.
Event Sourcing (Log)
Model :
- Source change STATE from A to B;
- Log this event : STATE changed from A to B;
- Source change STATE from B to C;
- Log this event : STATE changed from B to C;
- Repeat ...
- List of STATE CHANGES in the LOG;
Usage :
- Audit the LOG
- Replay the LOG
- From SCRATCH (begining) to the end
- From SNAPSHOT (a working copy) to the end
Note :
- A list of CHANGES or STATES;
Pros :
- A strong audit capability (accounting transactions are an event source for account balances).
- Recreate historic states by replaying the event log up to a point.
- Explore alternative histories by injecting hypothetical events when replaying.
Cons :
- Replaying events becomes problematic when results depend on interactions with outside systems.
CQRS
Note :
- Command Query (Write/Read) Responsibility Segregation
- Having separate data structures for reading and writing information
- Not really a EVENT model
- Command/Write/Modifier/Mutator
Usage :
- A single model to handle both reads and writes gets too complicated, and we can simplify by separating the models. Or lots of reads and very few writes.
- But the gain for using CQRS has to be balanced against the additional complexity of having separate models.