Event Driven

Flow of the program determined by events

Photo by Firmbee.com on Unsplash

Pattern 1: Event Notification

E.g. Customer management system emits an event object to a well-known place (e.g. event queue) and insurance quoting system can listen for that event.

E.g. GUI elements

Advantage

1. It allows many other systems to hook up to the event stream very easily and those systems do not need to know or care about the system emitting the event.
2. Decouple receiver from sender

Disadvantage

1. You don’t know what behaviours you will trigger

Pattern 2: Event-carried State Transfer

Pattern 1 的進化版

A less common pattern

E.g. Customer management system emits an event object with all data which downstream systems need, and downstream systems copy a part of data they are going to use

Advantage

1. It allows many other systems to hook up to the event stream very easily and those systems do not need to know or care about the system emitting the event.
2. Decouple receiver from sender
3. Reduced load on supplier

Disadvantage

1. Consistency problem

Pattern 3: Event Sourcing

We preserve important state-changed events in the “log” instead of preserving states in an application

E.g. Git, accounting system

Asynchrony

Asynchrony can be used for event sourcing but not necessary

E.g.

• commit at local => synchrony
• local + shared repo (e.g. Github) => asynchrony

Advantage

1. Great for audit
2. Great for debugging (time traveling)
3. To have historic state and alternative state
4. Save data in memory (?

Disadvantage

1. 對大多數人來說是一個陌生的系統 => 不易共同作業
2. To talk to external system gets more complicated

Pattern 4: CQRS

• Command Query Responsibility Segregation

https://www.youtube.com/watch?v=STKCRSUsyP0&list=WL&index=5&t=2000s

• Basic idea: Separate the components that read (dealing read) and write (dealing update) to the permanent store.

References

1. The Many Meanings of Event-Driven Architecture • Martin Fowler • GOTO 2017
2. 事件驅動伺服器：原理和實例

v8 engine (emitter), see node implementation