Event Model 笔记

Resource

https://martinfowler.com/articles/201701-event-driven.html

Digest

Abstraction

	Event Notification	Event-Carried State Transfer	Event Source	CQRS
Key Usage	Send State ID in Message Listener to Query new State	Send whole State in Message Client side Redudency	Log all the state Change/Delta	Seperate READ and WRITE

Event Notification

Model :

1. Listener : Register as Listener of Source;
2. Source : State Change
3. Source : Compose Event Message
4. Source : Notify Listeners
5. Listener : Decompose Event Message
6. Listenter (Optional) : Fetch More Information from Source with IDs in Event Message 
7. 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 :

1. Listener : Register as Listener of Source;
2. Source : State Change
3. Source : Compose Event Message (ID + New State)
4. Source : Notify Listeners
5. Listener : Decompose Event Message
6. Listener : Get the New State from decomposed message
7. 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 :

1. Source change STATE from A to B;
2. Log this event : STATE changed from A to B;
3. Source change STATE from B to C;
4. Log this event : STATE changed from B to C;
5. Repeat ...
6. List of STATE CHANGES in the LOG;

Usage :

1. Audit the LOG
2. 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. 

转载于:https://my.oschina.net/u/3551123/blog/994062