Design Level EventStorming
The value of EventStorming is the active engagement that you achieve with the Domain Experts. In this case Nick and the Team are actively engaged in learning as much as they can, as quickly as possible about Nick’s Domain: A Roast-to-Order Coffee Business.
But what do we do with this Artifact after we’re done with getting the Big Picture of the Domain? How is this progressing towards the Team writing code and developing a prototype? This is where Nick and the Team have another EventStorming Session known as the Design Level EventStorming.
Most of the same rules apply in the Design Level EventStorming, however our outcomes change. We’re looking to start viewing the system in a way that’s more close to Tactical Domain-Driven Design. Our legend changes (diagram borrowed from Alberto Brandolini’s book Introducing EventStorming):
Brandolini describes two options for starting the Design Level session:
- Start from scratch
- Work on the existing model
In Nick and Team’s case, they’ll start from scratch because they are designing this system from scratch and expect the design surface to grow significantly. In a scenario where the Big Picture Session was geared toward a brownfield development project, they might choose to work on the existing model.
Bounded Contexts
The team begins to make an attempt to unify the Big Picture Artifact into a view of the Domain that they can build a Domain Model in code for.
The first thing they want to do is better identify Bounded Contexts based on their discussions and the visual separation they see in the Big Picture Artifact.
They decide to start drawing lines to group their Domain Events separate Subdomains:
They come up with 6 Bounded Contexts:
- Green Bean Inventory
- Roast Planning
- Roast Execution
- Order Fulfillment
- Coffee Sales
- Customer Relations
With these preliminary Bounded Contexts mapped, Nick and the Team can identify what is Core…
.@yreynhout Ask "What is core?" After finding the core, everything else is relative and subjective. Well, just in case you value my opinion.
— Vaughn Vernon (@VaughnVernon) October 3, 2016
Competitive Advantage
Greg Young suggests using Agile Estimation to help identify what is Core and what teams should actually be applying Domain-Driven Design to versus just CRUD or 3rd Party. On one side, there is the Competitive Advantage that a Bounded Context brings to your business. On the other side, there is the Complexity/Cost that is associated with implementing software to manage the Bounded Context
| Bounded Context | Competitive Advantage | Complexity/Cost |
|---|---|---|
| Green Bean Inventory | ||
| Roast Planning | ||
| Roast Execution | ||
| Order Fulfillment | ||
| Coffee Sales | ||
| User Management |
See this article for more on Agile Estimation. Greg Young suggests to use the scoring system that your team uses. We’ll say that the Team uses T-Shirt sizing (the scoring system Greg uses in his DDD/CQRS training).
Nick and Team start asking what each Bounded Context contributes to his business’s Competitive Advantage.
Team: How much does managing Green Bean Inventory contribute to your business’s Competitive Advantage?
Nick: I’d say a Medium. I can always manage my Inventory by hand, it’s not Core to my business’s Competitive Advantage, everyone has to manage their Inventory somehow.
Team: How much does Roast Planning contribute to your business’s Competitive Advantage?
Nick: Large. What sets me apart is that I’m going to be transparent with the Customer about the roasted coffee that they’re buying. They’ll know how much I’m roasting every day and only be able to buy the coffee that has my complete focus through the process.
Team: How much does Roast Execution contribute to your business’s Competitive Advantage?
Nick: I’d say a Large.
Team: How much does Order Fulfillment contribute to your business’s Competitive Advantage?
Nick: Small, I’m just getting off the ground. If I don’t have automation in this context, I can make up for it manually until it really starts to bog me down.
Team: How much does Coffee Sales contribute to your business’s Competitive Advantage?
Nick: Large
Team: How much does User Management contribute to your business’s Competitive Advantage?
Nick: Medium
Here’s what they come up with after some more discussion:
| Bounded Context | Competitive Advantage | Complexity/Cost |
|---|---|---|
| Green Bean Inventory | M | |
| Roast Planning | L | |
| Roast Execution | L | |
| Order Fulfillment | S | |
| Coffee Sales | L | |
| User Management | M |
They can now proceed in trying to compare the perceived complexity around solving Nick’s business problems through software automation…
I will be releasing most of this content only to subscribers. Make sure you sign up by clicking the big red button!
Related Posts:
- People and Commands
- Hotspots
- Domain Discoveries
- Big Picture EventStorming
- The Domain - First Pop Coffee Company
- More Efficient Domain Modeling with EventStorming
- Where do you find resources for learning DDD, CQRS, Event Sourcing, and EventStorming?
- Has the code devolved into a big ball of mud?… What can you do about it?
- A Better Way to Project Domain Entities into DTOs
- Exposing IQueryable in a CQRS Query Stack
- A Pattern to Decouple your Aggregates from their Clients
- Erlang-style Supervisors in C# with Akka.NET and the Actor Model