8. What is “Event Sourcing” anyway?
Event sourcing refers to a collection of patterns based on
persisting the full history of a domain as a sequence of
“events”
rather than persisting just the current state
9. Reminder: The Domain Model pattern
An object model of the domain
that incorporates both behavior and data
Use when you have complicated and everchanging business
rules
If you have simple not-null checks and a couple of sums to
calculate, a Transaction Script is a better bet
- p119 Patterns of Enterprise Application Architect, Fowler et
al.
11. OK, so what is an “Event” then?
Historically speaking, first they were called “Interrupts”
These were signals to the processor
that something needed immediate attention
Keyboard and mouse clicks are a kind of Interrupt
12. And then came the Graphical User Interface
When a button was clicked, you got an “event”
a programming construct different from a class, method, or
pointer
You could register multiple “callbacks” for an event
which were essentially methods on a class, with arguments
which gave additional data about the event
13. Oh, so many arguments…
Private Sub object _MouseDown(
index As Long,
ByVal Button As fmButton,
ByVal Shift As fmShiftState,
ByVal X As Single,
ByVal Y As Single)
Then came the idea to use the Parameter Object pattern to
consolidate all the arguments together
15. Component-Orientation was significant too
The idea was that complex software was better built as a
collection of loosely-coupled & highly-cohesive components
On top of that, events were a communication style that was
even more decoupled than invoking methods on an interface
This became known as Event-Driven Architecture (EDA)
There were “event producers”, “event consumers”, and
“channels” that connected them
Tip: producers can also be consumers, and vice versa
16. Integration pushed EDA & Messaging together
Integration between applications on different platforms was
hard
Message-oriented middleware made it easier
The events being emitted by systems following EDA were
well-suited to being transmitted by messages
The name of the event was put in the header of the message
(used for routing), and the arguments in the body
Content-based routing came later
17. Where we are today:
An Event is a kind of data structure (name + key/value args)
which represents an action that has already occurred
Infrastructure helps move these events around
Whether between systems using messaging
Or for persistence with event-sourcing
20. If you’re building a complex system…
UI
BL
DAL
DB
API
This isn’t your
Domain Model
21. Models of your domain
public class Customer
{
FirstName
LastName
Status
// etc
}
public class Product
{
Name
Description
Price
// etc
}
Customer
Status
Product
Price
Customer
FirstName
LastName
Product
Name
Description
TX Script TX ScriptDomain(?)
25. Events on the outside vs inside
Sales Billing
Shipping
Order Accepted
Order Accepted
Order Billed
26. Auditing & Replay
Messaging infrastructure usually provides Auditing out-of-the-
box
Once you have auditing in place, Replay becomes possible
To be totally honest, there are so many challenges with
Replay
like when integrating with other systems, that it just isn’t worth
it
(except in edge cases).
27. Events on the outside vs inside: Notifications
Shipping
28. Events on the outside vs inside: Data Sync
Billing
Master DB
Oracle
Finance
SAP
Data
Warehouse
Change
Data
Capture
ETL
29. Product Catalog
Events on the outside vs inside: DB Replication
Write Master
Read ReplicasRead ReplicasRead ReplicasRead ReplicasRead Replicas
Async
DB Client SDK
CRUD
30. Sales: customers who bought X also bought A, B, C
Events on the outside vs inside: Graph Databases
Graph DB
31. Monitoring
(IT/Ops)
Events on the inside: Time Series Databases
Influx DB
Netflix
Atlas
This is where we find event logging & tracing
36. Below scale, Moore’s law is your friend: Scale UP
Biggest AWS EC2 Instance: 128 vCPU, 3904 GB Memory
Reserved instance 3 year term:
$6250/month
That’s cheaper than most developers
I got to tell you, the things I’ve been hearing about this “event sourcing” thing.
People are treating it as
It does the scaling, the consistency, the auditing, the modeling, the time to market…
And I got to tell you, it sounds like the promises I’ve heard from…
So, yeah, naming things is hard, but there’s so much more than just Event-Blah.
There’s also Service-Oriented Architecture, Microservices, Domain Models, DDD, and even CRUD.
I’ll be touching on some older computer history along the way, so please bear with me.
A “pattern” is a solution design for a certain problem context. It is not a “best practice”.
Event-sourcing has a whole bunch of ramifications that many of the other speakers will talk about today, so I want to focus on setting the stage here.
Now, a lot of you already know the Domain Model pattern, or at least think you do, but here’s a friendly reminder just in case.
And in the darkness bind them.
But we’ll get back to this idea of having multiple domain models – event-sourced or otherwise, a bit later.
Note there was nothing about Event-Driven Architecture which meant it had to be distributed.
1. The thing was, there was no interoperable pure event-based model that worked at the time. There still isn’t – not really.
Now, remember that we said that Event-Sourcing is based on the Domain Model pattern? Right.
And remember what we said about the domain model?
Use when you have complicated and everchanging business rules
“If you have simple not-null checks and a couple of sums to calculate, a Transaction Script is a better bet”
All the way down through the database, and all the way up through the UI
Whether you’re using SignalR, or Azure Notification Hubs, or Google Cloud Messaging – this is about pushing data updates to your users.
You might be familiar with the concept of Projections in Event Sourcing, for creating read models that are quick and easy to read from.
Almost all databases already have this functionality built-in.
You won’t see domain models everywhere.
You won’t see event-sourcing everywhere.
Each area becomes a special case.
If you look at how databases do replication – you’ll see Event Sourcing patterns.
If you look at how Time Series Databases work, you’ll also see Event Sourcing patterns.
Things like Event Replay are a great way to get a new database node up and running in a cluster.
If/when existing database technologies just don’t handle the scale you need, you’ll use Event Sourcing patterns to build your own.
Seriously, I’ve seen far too many systems where the over-engineered complexity was what hurt its performance, to the point where even scaling up didn’t help.
Start simple.
Accept that you’ll need to redesign the system over time.
Explain that to stakeholders. That this is *normal*.
And that’s the most important thing. That the business can continue doing what it needs to do, and lives to fight another day.
I know I’ve just barely scratched the surface on these ideas, so if you want more, check out my videos on this link.
And I hope you’ve