Event Storming and Model Storming Notes

Notes based on Model Storming - A presentation by Ziobrando (Alberto Brandolini)

• Software development is a learning process. Working code is a side effect
• Aim is to improve learning and decision making.
• Event storming in a nutshell: 0) Unlimited modelling space, 1) Domain events, 2) Commands and external systems (persona and user stories), 3) Aggregates (Key test scenarios - given, when, then).
• What is Model Storming? 0) Unlimited modelling space, 1) Simple gaming rules, 2) active collaboration, 3) addressing complexity, 4) everything is visible, 5) supporting divergence, 6) Decide later
• Our brain doesn't learn under stress, provides inferior solutions under pressure, tries to preserve energies.
• Data first, structure later.
• We need at least three bad ideas (I LOVE THIS IDEA).
• It's awesome. 35 people means 35 interpretations of the domain.

Notes based on Event Storming Recipies - A presentation by Ziobrando (Alberto Brandolini)

• Invite the right people to the party - Those who bring the questions, those who know the answers.
• Value in in the interaction between people. If key people don't show up, make them regret it. Tell them they missed the party, but more importantly, that they are invited to the next one.
• Use a large paper roll. You need unlimited modelling space, because you can't tell the size of a problem before exploring it.
• Domain events: Simple, semantic and easy to grasp by everyone in the room. E.g. Item purchased, invoice sent, invoice paid.
• Along a timeline: Enforce narratives. People like telling stories, not just filling diagrams or templates. Encourage experts to tell stories. Look for concrete examples and edge cases. You can eventually turn them into tests.
• Sketch acceptance tests: Given a registered user Bob and Bob is a premium customer, when Bob purchases goods for $100, then Bob is given a 20% discount.
• Reverse narrative: What was the path that led us here? What needs to happen before, so that this event can happen too?
• Look for pivotal events. What does trigger events? A command from a given user, or an external system? Or simple the time (end of month), or just another event (item added to cart, (something magic happens here), price updated.
• The word 'whenever' is important. Whenever we receive an invoice we schedule a payment.
• In many companies, the bottleneck in not in the actions, but in the decisions. There are huge areas for improvement here.
• Modelling commands and read models. Things a user needs to see in order to make a decision (only 1 item left - availability).
• What really happens in event storming? Conflicts and potential overlappings are highlighted, can finally see the big picture, conversations can finally happen, ideas are popping out.