2
„The single biggest problem in
communication is the illusion that it has
taken place.“
George Bernard Shaw
Slide 3
Slide 3 text
Everybody Loves Events
Slide 4
Slide 4 text
@lutzhuehnken
Great!
Slide 5
Slide 5 text
@lutzhuehnken
Event Collaboration
Slide 6
Slide 6 text
@lutzhuehnken
How it started
Slide 7
Slide 7 text
@lutzhuehnken
How it’s going
Slide 8
Slide 8 text
@lutzhuehnken
Slide 9
Slide 9 text
@lutzhuehnken
What’s the problem with this?
Slide 10
Slide 10 text
10
Definition: Event
An event is a fact. It’s an observation of something that has
happened in the past.
Slide 11
Slide 11 text
@lutzhuehnken
What’s the problem with this?
Slide 12
Slide 12 text
@lutzhuehnken
But isn’t that also Event-driven?
Not the fact that it’s asynchronous makes something an event.
Not the fact that Kafka is being used makes something an event.
Event is a specific kind of message, with specific semantics.
Slide 13
Slide 13 text
@lutzhuehnken
With events, there’s no going back. If a receiver can’t process an event,
it’s their problem. And this is beautiful! It’s what allows us to build this:
instead of this:
Slide 14
Slide 14 text
@lutzhuehnken
Not All Events Are Interesting
UI Events (ButtonClicked,..)
Log Events
Outside World Events
Slide 15
Slide 15 text
15
Definition: Domain Event
A domain event is a fact. It’s an observation of something
interesting that has affected the domain.
Slide 16
Slide 16 text
@lutzhuehnken
How Domain Events Usually Come About
Slide 17
Slide 17 text
@lutzhuehnken
Temporal Decoupling
Slide 18
Slide 18 text
@lutzhuehnken
Event Sourcing?
Slide 19
Slide 19 text
@lutzhuehnken
Slide 20
Slide 20 text
@lutzhuehnken
Event Sourcing Inside
Slide 21
Slide 21 text
@lutzhuehnken
With CQRS
Slide 22
Slide 22 text
@lutzhuehnken
With Event Streaming
Slide 23
Slide 23 text
23
Definition: Event Sourcing
Instead of storing the current state of something, store a sequence
of events that lead to the state.
Slide 24
Slide 24 text
@lutzhuehnken
Event Sourcing
This happens inside your service!
Typical technology: Any ol’ database (SQL, noSQL, eventstore, ..)
(log-based message bus is also possible)
It’s an approach to data persistence.
Slide 25
Slide 25 text
25
Definition: Event Streaming
Publish a stream of events on a topic that other service can
subscribe.
Slide 26
Slide 26 text
@lutzhuehnken
Event Streaming
This is the basis for Event Collaboration between services!
Typical technology: Log-based message bus (Kafka, Pulsar, Kinesis,
EventHubs, PubSub,…)
It’s an API.
Slide 27
Slide 27 text
@lutzhuehnken
Listen to your own events?
Slide 28
Slide 28 text
@lutzhuehnken
We talked about this..
Slide 29
Slide 29 text
@lutzhuehnken
You can do Event Sourcing Without:
- Event Streaming
- „listen to your own events“ from an external bus
- Kafka
Slide 30
Slide 30 text
@lutzhuehnken
You can do Event Sourcing Without:
- Event Streaming
- Event Streaming for Collaboration (outside), Event Sourcing for
Persistence (inside)
- „listen to your own events“ from an external bus
- Just one very special way of Event Sourcing with questionable benefits.
- Kafka
- There was Event Sourcing before Kafka. (But it’s great for event streaming.)
Slide 31
Slide 31 text
@lutzhuehnken
And the other way around (Event Streaming and Event
Collaboration without Event Sourcing)
Slide 32
Slide 32 text
@lutzhuehnken
Fowler’s Types of Events
Event Sourcing Events
Notification Events
Event-carried State Transfer
Slide 33
Slide 33 text
@lutzhuehnken
Event Sourcing Events
As covered - complete unrelated to Event Streaming / Event
Collaboration.
Persistence for „Data on the Inside“
Separation from collaboration should be clearer.
Slide 34
Slide 34 text
@lutzhuehnken
Notification Events
- Temporal decoupling is lost
- Immutability may be lost
Recommendation:
- Only use references to immutable objects.
- Use where payload is too big (e.g. generated documents)
Slide 35
Slide 35 text
@lutzhuehnken
Event-carried State Transfer
What we usually think of when we think of Domain Events.
Can be further broken down, e.g. Fat Events.
Slide 36
Slide 36 text
Non-Events
Slide 37
Slide 37 text
@lutzhuehnken
Things that are not Events
Commands
- express an intention
- can fail
Queries
- ask for information
- return a result
Slide 38
Slide 38 text
@lutzhuehnken
Commands & Queries
Slide 39
Slide 39 text
@lutzhuehnken
Events
Slide 40
Slide 40 text
@lutzhuehnken
And this is beautiful! It’s what allows us to build this:
instead of this:
Slide 41
Slide 41 text
„It is not the things that matter in
early stages of design…
…it is the things that happen.“
Russ Miles
https://web.archive.org/web/20210126062147/http://www.russmiles.com/essais/going-events-first-for-microservices-with-event-storming-and-ddd
41
Slide 42
Slide 42 text
@lutzhuehnken
Event-driven only on paper..
Slide 43
Slide 43 text
Summing it up..
43
Slide 44
Slide 44 text
@lutzhuehnken
Caveat Emptor
If someone says Event Sourcing (or Events First), you must ask them
to explain what they mean!
Event sourcing within a service / bounded context?
Or „data inside out“, with the message bus as permanent storage,
i.e. using event streaming with infinite retention of events?
Slide 45
Slide 45 text
@lutzhuehnken
Recommendation
Be weary of „data inside out“ patterns where the transport between
your services becomes the permanent storage and source of truth.
Better:
Clearly separate between data on the outside (think transport, not
storage) and data on the inside (source of truth, persistence,
governed by domain)
Slide 46
Slide 46 text
@lutzhuehnken
Design
Event-driven architecture doesn’t just happen.
You have to design your processes in a way that you can leverage
the advantages of event-driven architecture.
Event Collaboration is the foundation of event-driven architecture.
Slide 47
Slide 47 text
PPT Master 16:9 / Edition 2018
„Going to microservices is like going from
Newton’s physics to Einstein’s physics.
Newton’s time marched forward uniformly
with instant knowledge at a distance. Before
microservices, distributed computing strove
to make many systems look like one with
RPC, 2PC etc.. In Einstein’s universe,
everything is relative to one’s perspective.“
Pat Helland