Martin Fowler – The Many Meanings of Event-Driven Architecture 

“The Many Meanings of Event-Driven Architecture”
@martinfowler

## Intro

This talk is based on https://martinfowler.com/articles/201701-event-driven.html

## Typical event scenario

user => (changes address) Customer Management => (Get Requote) Insurance Quoting => (Send Email) Communications

## Request/Response style

Implied problem: dependencies NOT inverted.

Cusomer management should not have to know about Insurance Quoting System.

We'd like to invert the dependency. How to do that?

  • Insurance Quoting polling constantly?
  • To get a more timely responce we emit an "address changed" message and Insurance Quoting subscribes

Classic way to invert dependency is to issue events, can be done at small level and large level. Call this "Event Noification"

### Note on terminology: Events or Commands?

Command = tell callee what to do

Event = more open ended

Although they are the same mechanics, the way you name them affects the way we treat them/think about them

Some events may be phrased as passive agressive commands

## Event Notifications

People love that pub/sub allows multiple consumers. Easy.

Great property of this pattern but also a problem because we lose the flow of the system and it is hard to reason about.

Note: GUI MVC relies on events.

Event notification:

  • Pro: Decouples reciever from sender
  • Con: No statement of overall behavior.
    • Trolling through logs to track a distributed transaction.
    • Harder to make changes safely

## Event-Based State Transfer ("Event-Carried" in the original article)

Can't be sure when your client needs more information. If your clients want to follow up for more information, you may allow your clients to now DDOS you.

Pros: even more decoupled from source, reduced load on supplier

Cons: replicated data (costly), eventual consistency problem (you really hate it when you notice it - you have to think about it/manage it)

-- alex note: seems like DB replication (though in db log shipping there is a closer relationship between primary/secondary?)

## Event Sourcing

Ex: Change my address. Dispatch a function to a Person Domain Object. Alternative: first thing is to create an event object and stick it somewhere. Then process the event.

True test of Event Source: can toss all state and re-build from events. EG Git "Example I like to give people, well programmers not normal people, it doesn't work on them"

Other example: bank account (your balance is application state)

Pros:

  • Audit
  • Debugging (can replay through an error scenario)
  • Historic State
  • Alternative State
  • Memory Image

Cons:

  • Unfamiliar
  • External Systems
  • Event Schema (changing schema are a pain)
  • Identifiers (if regenerating)
  • ? Asynchrony - merge event streams is an async event (commit is not)
  • ? Versioning

Implementation wrinkle: manage snapshots as you go (recomputing entire event log too expensive)

### Ex: Widget purchase system

Input even: buy 15 widgets

output event: 15 widgets total 33$

internal event: buy 15 widgets: price 30$, discount 3$, shipping: 5$, total: 33$

you have to then save the internal events in the event that the internal event calculation. you lose some flexibility. Keep both internal events and output events?

Doing a refactoring: EG renaming a function. Touching lots of files.

Note: there was a bug in the 33$ calc. Now what?

-- alex note: see recent crypto-currency problems- https://zcoin.io/language/en/zcoins-zerocoin-bug-explained-in-detail/

Note that all three patterns are distinct so far

## CQRS (Command Query Responsibility Segregation)

Query model and command model different

Completely different services, maybe even different models

Martin hears more complaints about this then any other pattern. "it is twice as much work"

Why is it problematic: Inherent problems? Done badly? Misused?

Treat with caution. Awkward to use tool.

### How different is it to have an operational and reporting database?

With CQRS: expecting sync reads - with reporting database there is expected lag

with CQRS: don't allow read from operational DB (not the typical op db/report db setup)