ddd: event storming notes

Rough notes from watching the video Alberto Brandolini - 50,000 Orange Stickies Later. In 2013, he wrote the seminal article Introducing Event Storming

• @4: Model the whole business.
• @5: use a big paper roll, represents time line, put on the wall.
• @5:40: Orange stickie for a domain event. Use a past tense verb and language that is relevant to the domain experts; for example, 'Item added to cart'
• @8: Impossibility of complete requirements. 'Gossip does not compile.' Many units in an organization suffer from self-preservation mode where the goal is to be the second worst group in the organization. That way, you never get into any trouble.
• @9: Put everyone together in the same room and use the timeline to try and build a common story. Use purple (or red, if you can find it) stickies for errors/problems. These will fall out from using a common timeline that everyone can see.
• @11: The business outcome is visible to all---this is what our company is doing.
• @12: Once the model is up on paper, you will start to see stories as flows/lines through time.
• @14: Use arrow voting to decide what areas are next to fix. #noestimates.
• @18:55: Some special tricks: incremental notation (?), fuzzy by design (leave things vague on purpose, do no get caught up in technical jargon that means nothing to the business.
• @21:08: Goal: make sure we are fixing the right thing.
• @23:37: stickie colors:
  • orange: domain event
  • blue: command
  • green: read model
  • lilac: policy (double-wide)
  • yellow: user (1/2 wide) or aggregate (double-wide)
  • pink: external system (double-wide)
  • red: problem area, common source of errors
• @24:49: Discovering policies is the key. Policies define the company. A policy says: 'Whenever this event then that command'. There can be implicit policies, which means there are no written rules but people have developed these habits as the best way to get their job done.
• @29:30: big picture: discovery---and disagreements are OK. Consensus is very hard, we are not trained to model in a collaborative way. (Desktop Visio or a whiteboard with one marker.)
• @31:31: Investigating Aggregates. Look for state machine logic and focus on behavior, not data. For example, 'what are the key bits of information that are triggering the behavior.' Don't get hung up on naming the aggregates, postpone this. Sometimes, event storming will make aggregate obvious---'there must be something here between this blue and the orange stickie.' (That is the definition of an aggregate.) What are the little, local decision making steps; for example, decide whether to accept or reject a command based on my internal information.
• @33:15: Ubiquitous Language: at a large scale, we wont have one. So slowly introduce this, as people tend to get stuck on their vocab. Domain events can probably be consistent names across departments, but don't bog down business with internal IT naming problems---keep it at the domain event level.
• 36:35: This naming process can seem pedantic and a waste of time but be on the lookout for a lack of symmetry [mb: I think this means where the domain export of the producing domain uses different language that the domain export in the receiving domain.]
• @44:58 Domain events are a really good choice for describing the business.
• @46:43: Presents a really good table that describes how the same set of Domain Event data can be used to talk at a very high level (execs) to a low-level.
• @46:54: Event Storming is a great platform for self-organizing teams. People won't self-organize around a system the don't understand.