This continuous state of change means that legacy architectures are insufficient or unsuitable to meet the needs of the modern organization. Applications must be able to run 24×7 with 5-9s (uptime of 99.999%), as well as be superelastic, global and cloud native.
to become real time, they must be event driven
A sequence of related events is commonly called a stream
This raises numerous questions. Is ordering important? Do I want to ensure transactionality? How do I trust the execution? Security? Lineage? Where did the event come from?假定事件已经发生了，不可变了，我们的领域模型需要做出什么样的changes来回应这些
CloudEvents的概念
In the real world, the nature of the “event” can be described as:
- Atomic: something happened (bid on an item, send an email, device temperature)
- Related: a stream or sequence of events (tracking a pricing change, device metrics changes over time)
- Behavioral: the accumulation of facts captures behavior
事件的一些特性
evnet-first所考虑的问题
How is the event treated within a system? All of the following questions get asked as the event-driven architecture is developed:
- Is it observable, and are the flows of streams behaving as expected?
- Is it trusted, meaning transactional, exactly one or at least once? Will it scale?
- Is stateless processing, such as filtering, projection, cleaning or enrichment required? Is stateful processing, such as aggregations or stateful sequence processing required?
- Is a materialized view against the stream required? How many transactions per second are required for a windowed view?
- Do we want to scale/fan/map out (parallelize), fan in/collect and, build materialized views?
- Does it support error handling, such as error flows and dead letter queue?
- Does it send and transform events from one stream into others (stream processing)?
- Does it react and drive intelligence from the state collected from a stream (stream processing)?
event-first vs event-command
传统的rest属于event-command，接口/方法/返回值都是确认的，也是同步的
但是event-first部分，只是发一个消息，不确认谁来？
Event-first analog: I walk into a room, generate an “entered room” event and the light turns on. This is a reaction to an event.
Event-command analog: I walk into a room, flip the light switch and the light turns on. This is a command.
The pure event-first approach described above demonstrates:
- Decoupling: Processors don’t know anything about upstream or downstream processors
- Encapsulation: There are clean boundaries between processors.
- Inverted knowledge: Knowledge and responsibility are reversed.
- Evolutionary change: The system and events can change over time.
- Event sourcing: When using a log and log-aware stream processors, we gain the ability to potentially rebuild and restore application state. It’s not a free lunch; the application state needs to be captured and managed.