Udi Dahan's keynote presentation from DDD Europe 2020 on Event Sourcing.

1. Event Sourcing @ DDD Europe
Keynote
Udi Dahan
@UdiDahan

2. I’m not old enough to say “get off my lawn” but…

3. The best thing since sliced bread!

4. Just like every other technology & methodology

5. This was documented as the Gartner Hype Cycle
Some of you are here
Hopefully,
we’ll get you here

6. So, here’s what we’re dealing with:

7. Let’s bring some order to the chaos

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.

10. Beware the One Domain Model to rule them all

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

14. Add strong-typing and an IDE…
Parameter Object

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

18. Before using Event Sourcing on complex systems

19. Beware the One Domain Model to rule them all

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(?)

22. Now, take these boundaries and extend them
UI
BL
DAL
DB
API

23. Data and screens get partitioned
DB DB DB DB

24. With business-level events between boundaries
Events (pub/sub)
B1 B2 B3
Event
Store
DocDB Shards

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

32. At scale, everything becomes custom

33. So, what’s Event Sourcing actually for?

34. Bi-temporal, Code as Data Domains

35. Event-sourcing is for building infrastructure

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

37. And the business will change along the way

38. Incorporate re-architecting time into your plans

39. No, it won’t be pretty, but it will be functional

40. Learn how to divide responsibilities
and get your boundaries right.
http://go.particular.net/dddeu2020
Want more?

41. Thank you
Udi Dahan
@UdiDahan