Events! Events Everywhere!

2 „The single biggest problem in communication is the illusion
that it has taken place.“ George Bernard Shaw

Everybody Loves Events

@lutzhuehnken Great!

@lutzhuehnken Event Collaboration

@lutzhuehnken How it started

@lutzhuehnken How it’s going

@lutzhuehnken

@lutzhuehnken What’s the problem with this?

10 Definition: Event An event is a fact. It’s an
observation of something that has happened in the past.

@lutzhuehnken What’s the problem with this?

@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.

@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:

@lutzhuehnken Not All Events Are Interesting UI Events (ButtonClicked,..) Log
Events Outside World Events

15 Definition: Domain Event A domain event is a fact.
It’s an observation of something interesting that has affected the domain.

@lutzhuehnken How Domain Events Usually Come About

@lutzhuehnken Temporal Decoupling

@lutzhuehnken Event Sourcing?

@lutzhuehnken

@lutzhuehnken Event Sourcing Inside

@lutzhuehnken With CQRS

@lutzhuehnken With Event Streaming

23 Definition: Event Sourcing Instead of storing the current state
of something, store a sequence of events that lead to the state.

@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.

25 Definition: Event Streaming Publish a stream of events on
a topic that other service can subscribe.

@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.

@lutzhuehnken Listen to your own events?

@lutzhuehnken We talked about this..

@lutzhuehnken You can do Event Sourcing Without: - Event Streaming
- „listen to your own events“ from an external bus - Kafka

@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.)

@lutzhuehnken And the other way around (Event Streaming and Event
Collaboration without Event Sourcing)

@lutzhuehnken Fowler’s Types of Events Event Sourcing Events Notification Events
Event-carried State Transfer

@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.

@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)

@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.

Non-Events

@lutzhuehnken Things that are not Events Commands - express an
intention - can fail Queries - ask for information - return a result

@lutzhuehnken Commands & Queries

@lutzhuehnken Events

@lutzhuehnken And this is beautiful! It’s what allows us to
build this: instead of this:

„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

@lutzhuehnken Event-driven only on paper..

Summing it up.. 43

@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?

@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)

@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.

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

Who can think of a good question?

Events! Events Everywhere!

Events! Events Everywhere!

More Decks by Lutz Hühnken

Other Decks in Programming

Featured

Transcript