Design Level EventStorming Continued

Now that the team has looked closer at the Bounded Contexts, it’s time to initiate a Design Level EventStorming session so the team can start writing code.

We’re going to look at a single Bounded Context that they determined as a candidate for deep investigation and Domain Modeling from the analysis above.

They decide to go right for the Core - Roast Planning. As Nick said before, this is Core for his business. He wants to be able to plan his roast schedule and make the roasted coffee from his plan the only product available for customers to buy. The Team decides to do an initial Design Level EventStorming Session for this Bounded Context.

Nick and Team fill in more detail of the specific Use Cases within the Bounded Context based on the Commands and Events that they identified in the Big Picture session. They start to think about the points at which the UI provides information to Nick so that he can make informed decisions about his Roast Schedule and the Coffee he plans to roast on a given Roast Day within the Roast Schedule. We see new stickie colors:

Pale Yellow - Thing
Green - Key Information

“Thing” and “Key Information” aren’t DDD/CQRS terms, but they have a direct translation to:

Pale Yellow - Aggregate
Green - Read Model

So although the Team hasn’t discussed at-length with Nick about the architectural principles behind DDD/CQRS, Nick has been directly involved in growing the Ubiquitous Language and allowing the Team to learn quickly about how they’re going to implement the Ubiquitous Language in their prototype.

Also notice we aren’t defining the names of Aggregates yet. Brandolini suggests that we “Postpone Naming”…

One of the most interesting tricks is to try to postpone aggregate (or big yellow stickies, I am trying to postpone that too) naming. This is hard, because at this moment everybody is thinking they have a good name for it, and the habit of naming things is really too strong. Try the other way round: - Look for responsibilities first what is this yellow sticky responsible for?

Introducing EventStorming

So the Team leaves the Aggregate stickies blank for now until they feel truly ready to start naming Aggregates.

They start to see the cyclical pattern emerge as they model the Read Models, Aggregates, and UI around the Commands and Events they identified in the Big Picture Session.

Brandolini shows us what he calls “The Picture that Explains Everything” (image from Introducting EventStorming:

And the same cycle “flattened”:

Roast Planning

For the sake of this course, we’ll focus on the core Events within the Roast Planning Bounded Context and try to go through the actual implementation of this Domain Model in code. This might give us an idea of the full, start-to-finish process; from Big Picture EventStorming to Domain Model implementation.

Here’s where the Team ends with its Design Level EventStorming for the Roast Planning Bounded Context:

previous…

I will be releasing most of this content only to subscribers. Make sure you sign up by clicking the big red button!

Related Posts: