Martin Fowler.

Event Driven Architectures. What do people mean by it? Common theme: something called an event. But really it's more open ended.

Thoughtworks internal conference in Denver.

Video

I. Event Notification

1. Event Notification: Dealing with subsystem coupling

Turns things inside out and allows systems to be decoupled.

This pattern applies in at the macro (subsystems) and micro level (text fields).

2. Objectification of time: The event itself being a first class thingamajig.

Encapsulates the time aspect nicely. Objectifies the thing.

Events and commands. What's the difference? The naming things.

Events: something happened. Commands: do something.

If you don't separate these things conceptually, it leads to reasoning problems.

3. Scale: Allows adding new throughput boosters without changing the architecture

A downside: no statement of overall behavior. Because it is not imperative, the only way to understand is to observe the running it.

II. Event-carried State Transfer

It's not always possible to keep everything inside the event. Or, deciding how much information to put in the event. Can I put so much in there so the systems don't need to communicate directly. Events: cause followon queries

a. Each subsystem keeps its data local. b. each event has enough to allow the local data to be updated and kept in sync.

But now you have the consistency problem.

III. Event Sourcing

Bring in the logs. Test: If at any time, you can blow away the current state, and replay the log, and you get back the same state.

Did a poll, "who uses this" was alarmed at the result. Resorted to observing that an SCM is an example of this.

In the banking world, an accounting ledger is the perfect example of this.

It's a combination of every single change, plus snapshots.

Some benefits: debugging is nicer. You can make copies. Can keep your system itself entirely in memory. Gave the famous lmax example.

Some downsides

Unfamiliar, External Systems, Event schema (JSON to the rescue?), Identifiers

Slip ups: trouble with event sourcing. Felt he had to do twice as much work. People conflate asynchrony with event sourcing. It doesn't have to be. It does add a lot of complexity. (How do you do event sourcing without adding asynchrony? Locking?) Trouble with versioning events. Easy refactoring: change the name of a function. How do you get all the callsites? Advice: Don't have any business logic between your event and its storage.

IV. CQRS

Separate the components that read and write from your store. You only ever write using the command thing. You only ever read from the query system.

You have to be wary of this pattern. People seem to get in trouble with this pattern. "My sense is that it really has to be deep down in the toolbag to pull this one out." He's been talking about having reporting databases for years; that's CQRS too. Pure CQRS is the "only ever write using the command thing."

original article.