How to use event storming to achieve domain-driven design

Key Decision: Use Event Storming Instead of Formal DDD

The Event-Storming Process

The beauty of Event Storming is in its ingenious simplicity. In physical spaces (prefer‐ red, when possible), all you need to hold a session of Event Storming is a very long wall (the longer the better), a bunch of supplies, mostly stickies and Sharpies, and four to five hours of time from well-represented members of your team. For a successful Event Storming session, it is critical that participants are not only engineers. Broad participation from such groups as product, design and business stakeholders makes a significant difference. You can also host virtual Event Storming sessions using digital collaboration tools that can mimic the physical process described here.

  • A large number of stickies of different colors, most importantly, orange and blue, and then several other colors for various object types. You need a lot of those. (Stores never had enough for me, so I got in the habit of buying online.) • A roll of 1/2-inch white artist tape.
  • A long roll of paper (e.g., IKEA Mala Drawing Paper) that we are going to hang on the wall using the artist tape. Go ahead and create multiple “lanes.” • At least as many Sharpies as the number of session participants. Everybody needs to have their own!
  • Did we already mention a long, unobstructed wall that we can tape the roll of paper to?
  1. Large competitive advantage/large effort: these are the contexts to design and implement in-house and spend the most time on.
  2. Small advantage/large effort: buy!
  3. Small advantage/small effort: great assignments to trainees.
  4. Other combinations are coin toss and require a judgment call.
  • Phase 1 (~30 min): Discover domain events
  • Phase 2 (~45 min): Enforce the timeline
  • Phase 3 (~60 min): Reverse narrative and Command Identification
  • Phase 4 (~30 min): Identify aggregates/bounded contexts
  • Phase 5 (~15 min): Competitive analysis

Introducing the Universal Sizing Formula

Bounded contexts are a fantastic starting point for rightsizing microservices. We have to be cautious, however, do not assume that microservice boundaries are synonymous with the bounded contexts from DDD or Event Storming. They are not. As a matter of fact, microservice boundaries cannot be assumed to be constant over time. They evolve over time and tend to follow an increasing granularity of microservices as the organizations and applications they are part of mature. For example, Adrian Cockroft noted that this was definitely a repeating trend that they had observed during his time at Netflix.

Nobody Gets Microservice Boundaries Perfectly at the Outset

The Universal Sizing Formula

To achieve a reasonable sizing of microservices, you should:

  • Start with just a few microservices, possibly using bounded contexts.
  • Keep splitting as your application and services grow, being guided by the needs of coordination avoidance.
  • Be on the right trajectory for decreasing coordination. This is vastly more important than the current state of how “perfectly” you get service sizing.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store