Keynote — Udi Dahan
Event sourcing intro (the natural order of things — as he put it XD) — event sourcing from first principles probably
Event Sourcing all of the things (excited about it) — The best thing since sliced bread — Every technology goes through this phase
aka Gartner Hype Cycle
It is a lot harder than it looks initially…
Main novelty ES brings in:
ES is a collection of patterns based on the idea of persisting the full history of a domain as a seq of events, rather than persisting just the current state
Domain Model pattern
Object model which incorporates both behavior and data
Use when having a complicated and ever-changing set of business rules (tx script is some times a better choice) — not a best practice
Don’t use it for everything (no for not complex stuff) — not a best practice
Beware of one Domain Model to rule them all (LOTR reference)
This is also true for Event Sourcing
Event — first events were called interrupts (hardware or software) — signals to the processor (keyboard, mouse clicks, etc…)
This evolved to UI (from a hardware level) eg. button clicked with multiple handlers introduced — this was a grand idea — stepped away from sequential programming
Event data was initially passed as arguments (event itself was just an enum like object)
Parameter object pattern (consolidate event arguments into the event itself) — started to create structure around this concept of events
Component-Orientation (Idea developing parallel to the above on the backend side)
Complex software is better built as a collection of loosely coupled — highly cohesive components
Events were a communication style (more decoupling than invoking methods on objects)
This became known as EDA (event-driven arch) — this is not event sourcing
EDA DOES NOT indicate that it is required nor implied that we are talking about distributed systems — it’s not about scaling it’s just about decoupling
Producers -> Channels -> Consumers — people get hung up on these terms and consider a component either a producer or consumer but not both
TIP: Producers can also be consumers and vice versa
In EDA everything produces events and everything consumes events
EDA made integration between systems easier — this is when EDA became DISTRIBUTED
Events started being used as a transport mechanism (primitive)
EDA and messaging blended together because of integration
Content-based routing came later — subscribe based on the payload of the event (contents) — not just the type of event
Where are we today:
Event is ad data structure -> name + key/values which represent an action that has already occurred
Most event sourcing goes wrong when dealing with a distinction between a business event and “other” events
Infrastructure moves events around (eg. persistence with ES, ora messaging systems to move between systems)
Before using ES on a complex system -> STOP FOR A SECOND!
The business layer is not your domain model!! eg. Customer, Product
Need to decompose these into something less monolithic — (it’s hard — why am I not surprised lol)
A lot of the data that users see and interact with is not really that complicated — you don’t need a domain model for that data…
Product price or customer status is different — these change a lot
A bunch of the logic affects multiple domain models (some change together)
POAE — transaction script for simple data
He implies that we should extract data that does not change and deal with that in a simple way, and extract other stuff
that does change (eg. prices, statuses) and make a domain model out of that because they have different reasons to change!
(We are talking about boundaries now)
Data and screens usually get partitioned
Enter Microservices — the boundaries usually go right through the middle of your entities — a product microservice
does not have to own everything about the product — (eg. pricing micro deals with prices, sales, billing, shipping)!!!
Things that happen within the boundaries are not necessarily event-oriented
Data on the inside vs data on the outside — paper recommendation
EntityCreated, EntityDeleted might be events inside of the boundary but are not high-level business events -> Order accepted, Order billed, Are!
Tracking and auditing can be done without event sourcing! this is a separate pattern (ES is a collection of patterns, remember)
On the business event-level there are so many challenges with replays
We are usually integrating with other systems and it’s simply not worth it (except edge cases) — it is usually not necessary.
Dont use event sourcing for integrations, there are other mechanisms
Dont use it just for the sake of scaling (if the domain is not complex and ever-changing) — read replicas usually will do if you need to scale for reading (or even rw replicas)
(It’s an infrastructure concern)
(This was a discussion about the events on the outside)
Events “on the inside”
Try to be specific about events, notifications vs events there is a difference (notification can be based on the business event)
A curious thing:
Udi says: A lot of the times where we think, we will use event sourcing is because of not being familiar enough with the alternatives ?!
- hm? This sounds fishy, when has Event Sourcing become a defacto standard and things like replication, sharding, monitoring solutions, graph databases are an unfamiliar “alternative” ???
A conclusion: basically don’t strive to use event sourcing everywhere, most of the time.
there are different solutions. I’d say, analyze your problem first, check for (I won't say alternative) existing solutions and only in the subset of cases do apply event sourcing,
try to separate infrastructural problems from domain problems
But, what is event sourcing for then??
Bi-temporal time — stuff valid as of, effective as of …
When this is an important part of your domain, ES “might be” an appropriate solution (probably in just one subdomain)
Event-sourcing is for building infrastructure also! — eg. influx db (well we know this, almost every transaction db has a log inside of it) — but again at Netflix, Amazon, Google scale …
When you are not at that scale Moore’s law is your friend! — You have a lot of headroom to scale vertically and horizontally ! eg. biggest aws ec2 instance consts $6250/monh — cheaper than a lot of
developers doing domain models, event sourcing, etc …
Monolithic deployments scale pretty damn well.
Basically you have to try to define your boundaries (bounded contexts) as well as you can.
An average system has a little bit of everything and this is the nature of things itself — it’s not perfect but it’s functional — don’t be ashamed of it
Essentially, don’t use Event Sourcing except in 5% of use cases XD
http://go.particular.net/dddeu2020 — videos bu Udi on how to divide responsibilities and get your boundaries right
NServicebus will now be free for dev use