event storming

reminds me of Microscope
quantity over quality: the perfect is the enemy of the good
err on being more specific (people will point out if it's not valid, but may not realize something is missing)
- avoid CRUD naming
not just events in the "Kafka message" sense. can also be things like "user downloaded app".
introduce complexity gradually (not all types of notes at once)
if there are duplicate events with different naming: is that intentional or accidental?
if this doesn't go well you can have trouble with the rest of the domain driven design modeling process

Timeline

roughly 20 minutes
take everyone's notes and put them in order, grouping related events
if there are duplicates with different wording, discuss: come up with ubiquitous language

roughly 25-30 minutes
come up with user stories
be specific: "seat 1a reserved" over "seat reserved"
are there any dependencies? ie things that have to happen first
- "reverse narrative" - go over right-to-left
label stories

Think about what other systems you'll interact with, or which will interact with you
label external systems
what system kicks off each flow? (user, external system, etc)

everyone goes over the board ("explicit walkthrough")
take turns leading
if people are talking about things for a long time, mark it as a hot spot and move on

"noun verbed": "payment confirmed", "seat reserved"
write things in past tense: it has happened and cannot be rejected
sticky notes (or a representation thereouf), left to right as the process progresses
be specific: "rejected due to insufficient funds" instead of "rejected": this opens us up to thinking about all the other reasons it could be rejected