3. A domain event is anything that happens that is of interest to a domain expert. The domain expert is not interested in databases, web
sockets, or design patterns, but in the business domain of the things that have to happen. Domain events capture those facts in a way that
doesn't specify a particular implementation.
http://techbeacon.com/introduction-event-storming-easy-way-achieve-domain-driven-design
http://ziobrando.blogspot.fr/2013/11/introducing-event-storming.html
If you start with data modeling, your thinking and conversations will
quickly digress into schemas, transactions, and other things that have
nothing to do with the business domain.
If you start from behavioral modeling, you'll get distracted as you break
down behaviors into tasks and link them into processes.
Those are implementation concepts, not business-domain concepts.
While there are myriad choices for representing data and
implementing behaviors, there are no alternatives for domain events.
Because domain events represent facts about the domain, these only
change significantly when the underlying business changes. Domain
events are thus a more stable and resilient scaffolding for your model.
Domain
Event
Why should you start with domain event
Explore the domain starting from Domain Events.
Item
Added
Order
Accepted
past-tense sentence
Invoice
Sent
Order
Received
"Something that has happened
in the past that is of interest to
the business"
4. A domain event is anything that happens that is of interest to a domain expert. The domain expert is not interested in databases, web
sockets, or design patterns, but in the business domain of the things that have to happen. Domain events capture those facts in a way that
doesn't specify a particular implementation.
Domain
Event
Explore the domain starting from Domain Events.
Item
Added
Order
Accepted
past-tense sentence
Invoice was
Sent
Order
Received
"Something that has happened
in the past that is of interest to
the business"
UserLogged
In
UserLogged
Out
UserAdress
Changed
Invoice was
generated
I [Mathias Verraes] personally prefer sentence-style event names (“A product
was added to a basket” vs “Product added to basket”). I believe this makes the
business people feel more comfortable.
Invoice was
Paid
Invoice was
Contested
http://techbeacon.com/introduction-event-storming-easy-way-achieve-domain-driven-design
http://ziobrando.blogspot.fr/2013/11/introducing-event-storming.html
http://verraes.net/2015/03/event-storming-storytelling-visualisations/
5. The first few steps go something like this:
• Write down a Domain Event on a sticky (preferably
something that happens at the end, like “Bill was paid”).
• Ask what happened before that (“Bill was sent”) and
before that, until you get to the beginning.
• Ask what caused the events to happen. Those are
usually Commands (aka user intentions), other events,
or simply the passage of time.
• Ask for what reason a Command can fail, and find the
rules that impact the outcome of the Commands. This
pushes you to discover alternative scenarios, missing
events, connections between distant events…
The group starts with domain events, walking through the model forwards and backwards to ensure that everything is covered.
An event might be the predecessor of the follower of another one. Place all of them onto your modeling surface (the convention is to use
orange stickies for this purpose) according to a timeline.
Domain
Event
timeline
A domain event is anything that happens that is of interest to a domain expert. The domain expert is not interested in databases, web
sockets, or design patterns, but in the business domain of the things that have to happen. Domain events capture those facts in a way that
doesn't specify a particular implementation.
Explore the domain starting from Domain Events.
http://techbeacon.com/introduction-event-storming-easy-way-achieve-domain-driven-design
http://ziobrando.blogspot.fr/2013/11/introducing-event-storming.html
http://verraes.net/2015/03/event-storming-storytelling-visualisations/
Happy path & What can go wrong?
6. Then the group adds the commands, or triggers, that cause the events, and considers all sources of commands, including users, external
systems, and even time.
Domain
Event
Command
?
Explore the origin of Domain Events
Domain
Event
Some events are the direct consequence of a user action —> represent it as a Command using a blue sticky note. Others are the
consequence of something happening in external systems or of the time passing, we’ll use a purple sticky note for them. In some other
cases, we’ll have events that will be the direct consequence of some other events. We’ll simply place the two events close together.
http://techbeacon.com/introduction-event-storming-easy-way-achieve-domain-driven-design
http://ziobrando.blogspot.fr/2013/11/introducing-event-storming.html
What does trigger events?
A command from a given user or an external system
The Time (e.g. end of month, end of week, midnight…)
Another event
…
7. Domain
Event
Command
Trigger ?
?
Explore the origin of Domain Events
Domain
Event
Then the group adds the commands, or triggers, that cause the events, and considers all sources of commands, including users, external
systems, and even time.
Some events are the direct consequence of a user action —> represent it as a Command using a blue sticky note. Others are the
consequence of something happening in external systems or of the time passing, we’ll use a purple sticky note for them. In some other
cases, we’ll have events that will be the direct consequence of some other events. We’ll simply place the two events close together.
http://techbeacon.com/introduction-event-storming-easy-way-achieve-domain-driven-design
http://ziobrando.blogspot.fr/2013/11/introducing-event-storming.html
What does trigger events?
A command from a given user or an external system
The Time (e.g. end of month, end of week, midnight…)
Another event
…
8. Domain
Event
Command
Trigger
Source Of
?
user
time
external system
…
?
?
Explore the origin of Domain Events
Domain
Event
Then the group adds the commands, or triggers, that cause the events, and considers all sources of commands, including users, external
systems, and even time.
Some events are the direct consequence of a user action —> represent it as a Command using a blue sticky note. Others are the
consequence of something happening in external systems or of the time passing, we’ll use a purple sticky note for them. In some other
cases, we’ll have events that will be the direct consequence of some other events. We’ll simply place the two events close together.
http://techbeacon.com/introduction-event-storming-easy-way-achieve-domain-driven-design
http://ziobrando.blogspot.fr/2013/11/introducing-event-storming.html
What does trigger events?
A command from a given user or an external system
The Time (e.g. end of month, end of week, midnight…)
Another event
…
!
Trigger
"
#
Trigger
"
9. Explore the origin of Domain Events
Item
Added
Order
Accepted
Invoice
Sent
Order
Received
UserLogged
In
UserLogged
Out
UserAdress
Changed
UserLogin
UserLogout
Change
Address
AddItem
Validate
Order
10. Domain
Event
Command
?
Aggregate
Look for Aggregates
Domain
Event
The group identifies aggregates that accept commands and accomplish events, and begins to group aggregates together into bounded
contexts. Along the way, key test scenarios, users, and goals are identified and incorporated into the model.
Instead of defining aggregates starting from the code, we’re taking an outside-in approach: the Aggregate is the portion of the system that
receives commands and decides whether to execute them or not, thus producing a domain event.
http://techbeacon.com/introduction-event-storming-easy-way-achieve-domain-driven-design
http://ziobrando.blogspot.fr/2013/11/introducing-event-storming.html
Explore Aggregates Outside-In
An aggregate can accept or reject
commands…
… and mostly needs only the data
needed for this purpose
12. Domain
Event
Command
Aggregate
The group identifies aggregates that accept commands and accomplish events, and begins to group aggregates together into bounded
contexts. Along the way, key test scenarios, users, and goals are identified and incorporated into the model. Finally, the relationships
between bounded contexts are added to create a context map.
Group Aggregates into bounded context
http://techbeacon.com/introduction-event-storming-easy-way-achieve-domain-driven-design
http://ziobrando.blogspot.fr/2013/11/introducing-event-storming.html
Domain
Event
Command
Domain
Event
Command
Aggregate
Command
Domain
Event
Domain
Event
Command
Aggregate
13. Order
Cart
User
Explore the origin of Domain Events
Item
Added
Order
Accepted
Invoice
Sent
Order
Received
UserLogged
In
UserLogged
Out
UserAdress
Changed
UserLogin
UserLogout
Change
Address
AddItem
Validate
Order
17. Facilitating
• Hang the first sticky yourself (a tip from Alberto, works really well)
• Know when to step back. Don’t do the modeling, guide the modeling
• Ask questions:
• Is there something missing here? Why is there a gap?
• How does this make money?
• How does the business evaluate that this is working? What are the targets, how will we know we’ve
reached them?
• For whom is this event of importance (end user, business, tenant,…) ?
• I can’t see this particular role, or type of user, in this model. Should they be on here somewhere?
• Change the direction, e.g. start at the end of the flow, move back in time, then later start at the beginning and
move forward.
• Interrupt long discussions. Visualise both opinions, and, very important: ask both parties if they feel their
opinion is accurately represented.
• Timebox, using pomodoro’s (25 minutes). After each pomodoro, ask what is going well and what isn’t. It’s a
good opportunity to move to the next phase (e.g. from adding events to adding causality, to drawing
aggregate boundaries). You may want to move on even if you don’t feel the model is complete.
• Constantly move stickies to create room for hotspots.
• Hang red stickies with exclamation marks, question marks, or other notes, anywhere you feel there’s
an issue.
• At the end, make a photo. Then tell them to throw the model away, and to do it over the next day. If possible
in the presence of other stakeholders.
• I personally prefer sentence-style event names (“A product was added to a basket” vs “Product added to
basket”). I believe this makes the business people feel more comfortable.
http://verraes.net/2013/08/facilitating-event-storming/
18. References
Steven A. Lowe - An introduction to event storming: The easy way to achieve domain-driven design (Oct. 2015)
http://techbeacon.com/introduction-event-storming-easy-way-achieve-domain-driven-design
Alberto Brandolini - Introducing Event Storming (Nov. 2013)
http://ziobrando.blogspot.fr/2013/11/introducing-event-storming.html
https://lh3.googleusercontent.com/-2x4VNk-s32g/UouhUvPHbWI/AAAAAAAAAi8/oicOlEmD7i4/w1405-h1123-no/Event+Storming
+Cards+-+all.jpg
Alberto Brandolini - Event Storming Recipes (Jun. 2014)
http://fr.slideshare.net/ziobrando/event-storming-recipes
Thomas Pierrain - Event storming: Domain distillation under steroids (Aug. 2015)
http://tpierrain.blogspot.fr/2015/08/event-storming-domain-distillation.html
Thomas Pierrain - Event Storming: my rookie mistakes (Aug. 2015)
http://tpierrain.blogspot.fr/2015/08/event-storming-my-rookie-mistakes.html
Emilien Pecoul (Ouarzy) - Event Storming (Sep. 2015)
http://ouarzy.azurewebsites.net/2015/09/23/event-storming-another-way-to-design-an-event-driven-architecture/
Mathias Verraes - Facilitating Event Storming (Aug. 2013)
http://verraes.net/2013/08/facilitating-event-storming/
Mathias Verraes - Event Storming, Storytelling, Visualisations (Mar. 2015)
http://verraes.net/2015/03/event-storming-storytelling-visualisations/