2. Event Storming is a rapid design technique that is meant to engage both Domain Experts
and developers in a fast-paced learning process. It is focused on the business and
business process rather than on data.
3. Introduction
● Alberto Brandolini
● Created because it was much more lightweight than UML
● Event storming is getting more and more popular in the DDD community
○ Vaughn Vernon has a chapter on it in Domain-Driven Design Distilled
4. Advantages
● Hands-on and collaborative process,
○ Everyone gets a pad of sticky notes and a pen and is responsible for contributing to the learning and design sessions.
● Both business people and developers stand on equal ground as they learn together.
○ Everyone provides input to the Ubiquitous Language.
● It focuses everyone on events and the business process rather than on classes and the database.
● By focussing on events we focus on outcomes, without worrying on how these outcomes are achieved.
● It is a very visual approach, which dismisses code from the experimentation and puts everyone on a level footing with the
design process.
● It is very fast. If you write something on a sticky note that you later decide doesn’t work, you wad up the sticky note and
throw it away.
○ It costs you only a penny or two for that mistake, and no one is going to resist the opportunity to refine due to effort
already invested.
● Your team will have breakthroughs in understanding.
○ Some will come to the session thinking that they have a pretty good understanding of the specific core business
model but still find there is a lot they don’t know.
● Everybody learns something. Whether you are a Domain Expert or a software developer, you will walk away from the
sessions with a crisp, clear understanding of the model at hand.
9. DDD: Domain Event
“An domain event is record of a significant business occurrence in an application”
“Your event name should be a statement of a past occurrence, a verb in the past tense.”
Examples:
● ProductCreated
● OrderSent
● AppointmentPlanned
10. Why events first?
If we focus on the data we will obscure the business process
For example:
We define a user object with fields like:
● Email
● Bankaccount
The business processes involved with this data are things like:
● WelcomeEmailSent
● InvoiceSent
These occur in very different parts and at very different times in the system (maybe even by different
subsystems). So by focusing on the data we obscure the business process.
11. Today's subject: EDSN connection process
We’ll start of with:
“CustomerSubscribed”
And end somewhere around:
“ConnectionClosed”