Skip to content

Short cheat sheet for preparing and facilitating event storming workshops

License

Notifications You must be signed in to change notification settings

wwerner/event-storming-cheatsheet

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

11 Commits
 
 
 
 
 
 
 
 

Repository files navigation

Event Storming Workshop Cheat Sheet

Event storming is a rapid design technique for software systems involving both technical staff and domain experts / business analysts. It best fits in a Domain Driven Design context and leans towards / prepares for Event Sourcing and CQRS. The technique was first introduced by Alberto Brandolini and picked up by Vaughn Vernon in Domain Driven Design Distilled. It is also taught as part of his iDDD Workshop series.

This cheat sheet aims to provide a short opinionated summary of preparing and facilitating an Event Storming Workshop. It is not intended to give a complete introduction to the topic, prior knowledge on DDD and Event Storming is required to make responsible use of this document.

Required Material

Preparation

Up front:

  • Invite both domain experts and developers. Personally, I’d aim for no more than 8. But since the modelling space is big, discussion groups will emerge, so more people could work well, too.

  • Schedule a session for no longer than 2 or 3 hours. Plan for follow-up sessions.

At the location:

  • Remove chairs from the room. People should walk around. Seats are poisonous, as Alberto puts it.

  • Prepare the legend in advance. Alternatively, for first time participants, create the legend iteratively as you go along as described in Execution. You can use pre-prepared cards like the ones attached to this document.

  • Prepare the modeling space. Use paper rolls taped to a large wall. 1 m x 10 m should be considered the minimum size. Bigger is better. Be prepared for having to expand the space.

  • Lay out sticky notes and markers.

Execution

Below you find the order Vaughn Vernon recommends. It is fine to add additional artefacts in a later step, but it is important to roughly adhere to the Event → Command → Aggregate → boundaries → view order.

  1. Create or line out the legend so the semantics of the color notes / annotations is well understood by all participants.

  2. Storm out Domain Events on orange stickies and place them on the modeling space in business process (= time) order. The name is a noun/verb combination in the past tense, e.g. ItemOrdered.

  3. If issues with the process or questions_ arise that are not immediately resolvable, mark them with purple or red notes.

  4. Some Domain Events will cause a business process to run. Note the name of the process on a lilac note and draw an arrow from the Event process to the process.

  5. When you feel you have captured most of the Domain Events, focus on the Commands that create those Events. Put them on light blue notes left to the Event they cause. Proceed from left to right on the timeline. The name is an action like OrderItem.

  6. If a specific user role performs the Command, note that on a yellow note left below the Command. I like to draw stick figures to distinguish them.

  7. When you think you have all Commands, note the Aggregates on yellow notes and place them a little higher between the Command that is executed on this Aggregate and the Events it causes. The name is a noun, like Item. If Aggregates are used multiple times, create copies and place them repeatedly on the timeline.

  8. Draw your Bounded Contexts (solid lines) and Subdomains (dashed lines) onto the modeling surface. You should do this only when you feel you have understood the boundaries well enough. Name the contexts using pink notes.

  9. Draw arrows to show in which direction Events flow between your contexts.

  10. Identify Views required for the user to carry out tasks in your system. Place them on green stickies below the Aggregates they operate on.

Optional additions:

  • UI Mock Ups along with the views

  • Acceptance Test sketches for important tests

  • User personas

  • Read models

Reference

The semantics of the various colors as mentioned in the text above are shown below for reference.

  • Domain Events - orange

  • Commands - light blue

  • Aggregates - yellow

  • Issues - red or purple

  • User Roles / Personas - yellow with stick figure

  • Views - green

  • Bounded contexts - solid line, names on pink notes

  • Subdomains - dashed lines

  • Event Flow - arrows

Further Information

About

Short cheat sheet for preparing and facilitating event storming workshops

Resources

License

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published

Contributors 3

  •  
  •  
  •