Keynote — Udi Dahan (DDD EU 2020 talk summary)

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!

Auditing

Tracking and auditing can be done without event sourcing! this is a separate pattern (ES is a collection of patterns, remember)

Replay

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

Announcement:

NServicebus will now be free for dev use