The Many Meanings of Event-Driven Architecture • Martin Fowler • GOTO 2017

This presentation was recorded at GOTO Chicago 2017. #GOTOcon #GOTOchgo

Martin Fowler - Author, Speaker, Consultant and General Loud-mouth on Software Development

ABSTRACT
During my career, I've often people heard people describe their systems as "event-driven". But when looking deeper that phrase seems to lead to some very different architectural assumptions. On a recent workshop we identified four different patterns [...]

TIMECODES
0:00 What people mean by EDA
00:51 How he came to write down common patterns of EDA and hold this talk
02:45 4 patterns detected
03:20 Pattern 1: Event Notification
08:33 Events vs Commands
11:30 Pro: Decoupling
13:50 Contra: inability to understand what is going on by stepping through the code
14:53 Pattern 2: Event-carried State Transfer
20:51 Pattern 3: Event Sourcing
32:11 Can be a very nice system development-wise
33:43 Downside of Event Sourcing
38:46 Which events to record in the event store?
43:31 Pattern 4: CQRS
47:39 Conclusion : How to use the knowledge about those 4 patterns

Read the full abstract here:

RECOMMENDED BOOKS

#EventDrivenArchitecture #EventDriven #SoftwareArchitecture #MartinFowler

Looking for a unique learning experience?

SUBSCRIBE TO OUR CHANNEL - new videos posted almost daily.

[-andymel]

*Timed index of the video*

0:00 What people mean by EDA

00:51 How he came to write down common patterns of EDA and hold this talk

02:45 4 patterns detected
People normally call their system "event-driven" if at least one of those patterns is in place

03:20 *Pattern 1: Event Notification*
Generic code notifies specific code by events
for example GUI elements

08:33 Events vs Commands
Events just indicate a change without expecting any particular response
Commands are telling some service what to do

11:30 Pro: Decoupling

13:50 Contra: inability to understand what is going on by stepping through the code

14:53 *Pattern 2: Event-carried State Transfer*
Subscribers don't ask for additional information after an event occured, all necessary state is given in the events.
Subscribers copy whatever they need.
Pro: can greatly reduce network traffic. Better availability because of the copied data
Contra: consistency
It's Less used

20:51 *Pattern 3: Event Sourcing*
Ability to rebuild the full state of the system by a persisted log of events
Event Sourcing works with your data like version control systems work with your code
Pro: "time traveling" like for debugging. use a copy of the system, feed it the events and see what happened

32:11 Can be a very nice system development-wise

33:43 Downside of Event Sourcing
- unfamiliar
- when I rebuild the state from the log I can't replay answers of external systems unless I record all answers as kind of events
- old event schema still has to work somehow with new versions of code
- IDs that are generated during replay are probably different than before
- Asynchrony is difficult for people (but it's optional. You can synchronously use event sourcing)
- Versioning (Snapshots can make that easier)

(Conclusion for me: Always remember that replay has to work for everything, otherwise there is no point in using event sourcing)

38:46 Which events to record in the event store?
Two events happen for a state change. One shows the intention (command), the other shows all the different changes that were done.
Events that show intention often hold specific knowledge, the EventStore normally should stay generic (git only knows txt, not the used programming language syntax)
It's important to think about which of those events are important to persist. Probably both.

43:31 *Pattern 4: CQRS*
Separate components for updating the system and reading from the system
Different views of the data are pretty common (e.g. a reporting database), the important thing here is that the command model is never used for reading from outside

47:39 *Conclusion* : How to use the knowledge about those 4 patterns
When you hear about a system being "event-driven" ask questions to find out what patterns they use. Because the term "event-driven" is too imprecise.
Have enough knowledge about each pattern to know where the problems are and what consequences they cause.

[DodaGarcia]

Mr Fowler has that enviable energy of a school principal in a movie who acts serious around the grownups but helps the kids with all the crazy shenanigans behind the scenes.

[Saturn]

After watching a bunch of talks where people clearly don't understand these systems, Martin Fowler truly does.

[hjklmn]

Love listening to this guy. Pure gem. How i wish I would have had the honor of starting my career under his guidance as a direct reportee to him.

[maximsaloduha]

Mr. Fowler is not only an excellent writer and knowledgeable on the subject, but he is also an excellent speaker and explains many things eloquently. Thank you!

[CosasCotidianas]

I think the talk was pretty clear and enriching. Thank you Mr Fowler.

[LethiuxX]

First class thingamajig deserves to be recognized for it's genius.
I tend to explain event sourcing to people as similar to a Git repository.
I believe that CQRS is useful for optimization, particularly when considering an ORM.

[lelev]

Martin Fowler, another great insight(s) that you shared here. Thank you

[charlesopuoro]

Martin Fowler, thanks a whole lot for your contributions to the Industry. I also love the way you convey knowledge. Love the humor too. Wondering why folks in attendance didn't even giggle. Thanks again and always.

[dogaarmangil]

34:11 The event schema issue mentioned here goes away once you start using semantic data for recording events (in formats such as JSON-LD), because in case of semantic data there is no schema to modify, only new vocabularies to add to the vocabularies already in use. Software that read/write events only have to add support for the new vocabularies while remaining 100% compatible with the events previously published.

[DodaGarcia]

I love that for the event sourcing part he became Greg Young and started asking "How many of you" for everything, nice touch

[rafaelveggi]

6:15 - those are wise words to live by.

[venkataramanamadugula]

Thanks for this great talk. I could learn a lot from this talk.

[pm]

This was rather useful.
Seems to me like the 1) Even notification and reversal of dependency and the 3) Event sourcing (nothing specific to events actually. Any journaled system does it) .... are the most important here.
The state replication use case is definitely something to be careful about... it opens up a can of worms of consistency problems with home-brew distributes state machines.
Also ... It seems a lot of systems promoting them selves as event-driven using message-queues and such could really do with ordinary async REST callbacks, since what they are doing is actually "commands" and not "events".
The event "queue" model seems most useful when you don't know what should be done about an event or who should do it - or when you have realtime or broadcast aspects where throughput is more important than dropped messages. (event streaming).
If you are just sending jobs of to someone to execute, you can really do with just maintaining a "saga" state of the transaction and have it updated by async REST-like HTTP calls between services. No need for a queue.

[ntitcoder]

Great talk that puts a structure over the broad topic.
There's one minor issue with using Git as example of Event Sourcing: Git actually stores snapshots of the whole state, instead of changes.

[hanspeterqwe]

Nowadays when I read blogs about microservices, "event carried state transfer" (with CQRS) is presented as an absolute necessity 95% of the time, which I think is severely violating "right tool for the right job" for the sole purpose of consultants being able to consult on an unnecessarily difficult topic.

[smcpovo]

Finally, I've got an understanding of this topic.

[michaelreardon]

This is a great talk, and has led me to some helpful incites. Like most commenters though, I'm only going to point out what I don't like. I’m having trouble digesting the notion that Command messages are going to make reasoning about the system any easier than Event Notification. I think that has more to do with asynchronous operations than with the names and expected behavior of messages.

Datomic solves the schema versioning by treating the schema as data: There is only one Universal schema. It's wonderful.

[Mafiozk]

Extremelly good speech! Keep on doing!