Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Event storming Notes

2,830 views

Published on

My notes on Event Storming

Published in: Software

Event storming Notes

  1. 1. « All models are wrong, but some are useful » George E.P. Box
  2. 2. Unlimited Modeling Space Domain Event Command Aggregate key scenario; notes; goal… External System
  3. 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. 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. 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. 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. 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. 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. 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. 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
  11. 11. Order Cart User http://techbeacon.com/introduction-event-storming-easy-way-achieve-domain-driven-design http://ziobrando.blogspot.fr/2013/11/introducing-event-storming.html 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
  12. 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. 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
  14. 14. Bonus Targets http://techbeacon.com/introduction-event-storming-easy-way-achieve-domain-driven-design http://ziobrando.blogspot.fr/2013/11/introducing-event-storming.html 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
  15. 15. 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/
  16. 16. 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/

×