Slide 1

Slide 1 text

No content

Slide 2

Slide 2 text

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

Slide 48

Slide 48 text

Who can think of a good question?