event storming notes

« All models are wrong, but some are useful »

George E.P. Box

Unlimited Modeling Space

Domain Event Command

Aggregatekey

scenario; notes; goal…

External System

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"

http://techbeacon.com/introduction-event-storming-easy-way-achieve-domain-driven-design

http://ziobrando.blogspot.fr/2013/11/introducing-event-storming.html



Domain Event


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/



http://verraes.net/2015/03/event-storming-storytelling-visualisations/

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




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?




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.


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 …



Domain Event

Command

Trigger ?

?


Domain Event








Domain Event

Command

Trigger

Source Of?

user time external system … ?

?


Domain Event






!

Trigger"

#

Trigger"




Item Added

Order Accepted

Invoice Sent

Order Received

UserLogged In

UserLogged Out

UserAdress Changed

UserLogin

UserLogout

Change Address

AddItem

Validate Order

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.


Explore Aggregates Outside-InAn aggregate can accept or reject commands… … and mostly needs only the data needed for this purpose



Order

Cart

User



Item Added

Order Accepted

Invoice Sent

Order Received

UserLogged In

UserLogged Out

UserAdress Changed

UserLogin

UserLogout

Change Address

AddItem

Validate Order



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


Domain Event

Command

Domain EventCommand

Aggregate

Command Domain Event

Domain EventCommand

Aggregate



Order

Cart

User


Item Added

Order Accepted

Invoice Sent

Order Received

UserLogged In

UserLogged Out

UserAdress Changed

UserLogin

UserLogout

Change Address

AddItem

Validate Order

Bonus Targets


persona

Carnet d’entretien Réparation Vendeur de « Carcasse » …

Exploring Subdomains Exploring Bounded Contexts Sketching User Persona Sketching Key Acceptance Tests Sketching Key Read Model Artefacts

Critical or ambiguous use cases might require a precise completion criteria

When discussions arise around meaning and semantics, multiple models are probably

involved

Different stakeholders will have different areas of expertise

Sometimes who is performing the action is more important than other details



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/

ReferencesSteven 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/



https://lh3.googleusercontent.com/-2x4VNk-s32g/UouhUvPHbWI/AAAAAAAAAi8/oicOlEmD7i4/w1405-h1123-no/Event+Storming+Cards+-+all.jpg

http://fr.slideshare.net/ziobrando/event-storming-recipes

http://tpierrain.blogspot.fr/2015/08/event-storming-domain-distillation.html

http://tpierrain.blogspot.fr/2015/08/event-storming-my-rookie-mistakes.html

http://ouarzy.azurewebsites.net/2015/09/23/event-storming-another-way-to-design-an-event-driven-architecture/

http://verraes.net/2013/08/facilitating-event-storming/


event storming notes

Software