Event Storming Cheatsheet

This is meant to be a reference document, not really a presentation. I find event storming is best learned by doing it alongside an experienced faciltator.

Transcript

1. David Julia Event Storming Cheat Sheet
2. Logistics • Need lots of wall space • Book the conference room for at least 6 hours for nontrivial domains. This is often an all-day or day and a half exercise. • Have tons of sharpies for people • Move most of the chairs out of the conference room or off to the side. Have fewer chairs than people to encourage people to stand, write, interact. • Take breaks. This is exhausting. When people start getting off topic, it’s break time. • Make sure you have tons of stickies of the correct colors ◦ Use Post-it super sticky notes, not just regular post-its. Nothing is worse than falling post-its during this. ◦ You can use roll-paper, taped up on the wall with blue tape (especially if you can’t get super sticky notes) ◦ You can also use a whiteboard, advantage is you can redraw bounded contexts and lines more easily, but sticky notes don’t adhere as well
3. Overall step 1. Events a. processes b. problems 2. Commands a. Users 3. Entities/Aggregates 4. Boundaries and Lines 5. Identify significant user views Source: Introducing Event Storming by Alberto Brandolini
4. Introduce the exercise • Have everyone introduce themselves, why they’re in the room, what their role is, etc. if not everyone knows each other • Ask people to bear with you, go with the chaos ◦ There will be many times where different groups are working on different parts of the model, and that’s good! ◦ Sometimes you’ll bring the group back together to review • What are you hoping to get out of it ◦ Learning ◦ Identify bounded contexts ◦ Sometimes, how to partition work effectively (within team or across teams) • Ideally you have some domain experts on hand that you’ve invited to the meeting in advance. ◦ Even if not everyone you want can attend, still have the meeting! They’re missing out- you can send them pics afterwards to show them what they missed out on so hopefully they attend the next one.
5. • Facilitator will place Red Stickies on hot spots with explanation of problem • Processes/Policies go on Lilac Stickies. ◦ Sometimes, outcomes of domain events can be processes ◦ Draw a line from domain event to process Storm Out The Business Process • Orange stickies for domain events • Verb in the past tense ◦ “Order Shipped” ◦ “Approval Denied” • Place events on a timeline, from left to right ◦ If unsure, just put them somewhere and move them later. ◦ If domain is very large, and you’re doing high level modeling, maintaining a timeline can get messy/tricky ▪ Try to maintain timelines within domains Tips: Don’t jump ahead. It takes time to warm up. Model fine-grained events if they are important to core do otherwise go coarse-grained and move on.
6. Storming Tips • Don’t jump ahead. It takes time to warm up. • Model fine-grained events if they are important to core domain, otherwise go coarse-grained and move on. • • If the domain is very broad, and you’re doing high level modeling, maintaining a timeline can get messy/tricky ▪ In that case, try to maintain timelines within bounded contexts
7. Create Commands/Actors • Capture commands on light blue stickies ◦ Things that cause domain events ◦ Eg. If event is “Order Refunded” command could be “Refund order” • Not all domain events are caused by commands (sometime events happen due to time passing) • Commands can cause processes to run • Use bright yellow stickies for specific user roles who perform commands • One command can trigger multiple domain events… dup it to the left of the events!
8. Associate Entities/Aggregates with Commands • Aggregates go on normal pale yellow stickies • Place them above command/domain events, connecting them • Can duplicate aggregates so you don’t have to move everything around!
9. Draw boundaries/Information Flows • Draw borders/boundaries for bounded contexts ◦ Can start w/pink stickies as labels first if not confident in boundaries ◦ Use solid lines for bounded contexts, Dotted lines for subdomains • Indicators of context boundaries ◦ Departmental divisions ◦ Business people disagree on term definitions for the same word • Draw arrows showing direction of domain events going between bounded contexts • Label bounded contexts with pink stickies
10. Identify Read models (Optional, good for CQRS) • Optional step, useful if doing CQRS • Identify significant, special views in green • Don’t need to identify every view, just key views • Label bounded contexts with pink stickies
11. Wrap up • Wrapping up with a quick 15 min retro is great • Can also lead to a more data-centric model storming on individual aggregates now that you have business context • If you did the exercise on roll-paper, roll it up and keep it around for a few days, edit it as you learn more. • Follow up discussions on what domain to tackle first can follow.
12. Appendix
13. Facilitation Tips • Feel free to introduce more colors of stickies as you go along to represent new things. It’s totally okay to evolve the modeling language • Create a Domain modeling legend as you go along. You can explain everything you will be doing up front, but stick to the • Make sure you have tons of sharpies for people • Don’t discourage people during generative stages, let them go crazy shooting off ideas, then consolidate them later. • Encourage people to write whatever they know. • As you go along feel free to focus the group’s attention on key areas • Ask lots of questions of the group, especially if you’re confused (chances are the model doesn’t make sense) • The primary artifact of the session is learning the domain. The domain model is a secondary artifact. • Pay attention to business organizational boundaries and whether they map to your bounded contexts. They largely should if possible.