Big Picture EventStorming
The Team helping Nick get his website going begins with an EventStorming session. This is so that both the software Team and Nick can get their heads wrapped around the Core Domain and make sure they are writing the right code. It’s essential that Nick uses 3rd party for the code the Team shouldn’t be writing because he has a limited budget.
This is EventStorming session is called the Big Picture event and it will be the first of a few EventStorming sessions while they develop the Ubiquitous Language and Context Map for the system.
I won’t define a lot of terms for DDD or EventStorming. I want the reader to do the homework for term definitions. What I’ll be doing is using capitalization to do 2 things:
- Emphasize important Domain-Driven Design terms that you can research on your own
- Emphasize important Ubiquitous Language terms that emerge through this discussion
I want to focus on end goals. At this point, we’re trying to achieve a working Context Map that we can prototype quickly so that Nick can evaluate whether the Team is on the right track with his business plan.
Our first Domain Event: “Coffee Purchased”
The Team asks Nick to think of an event that will happen in the core of his business. He wants to be very customer-focused, so he writes Coffee Purchased on an orange stickie and slaps it up on the board. This is what he’s hoping for the most, obviously.
What else is he envisioning as core to his business? There’s the idea of his “Roast Schedule” so he puts Roast Schedule Created as another Domain Event. In order for him to make good decisions while he plans his Roast Schedule, he’ll have to monitor his Inventory of green, un-roasted coffee beans. So the next Domain Event: Inventory Checked.
Momentum
Minus a couple periods of silence, broken by the Team putting a random Domain Event up on the wall (a technique used by Event Stormers coined “Icebreaker”), the Team continues to fill in a timeline of Events across Nick’s roast-to-order business domain.
As Nick and the Team start putting more Domain Events on the EventStorming surface, questions or “Hot Spots” start to emerge:
- Is the primary unit of measure 1 lb of coffee?
- Is Nick going to always roast a fixed # of lbs of coffee per day?
- Or will Nick be able to roast more coffee one day and less on another?
We always note them on purple stickies and slap them on the wall near their respective Domain Events.
Terms that Nick defines as a Domain Expert start to emerge:
- Green Bean: Coffee that hasn’t been roasted yet. Purchased in bulk, either 50 or 100 lb bags.
- Roast Schedule: The outlay of Nick’s production week where he plans to roast x lbs of green beans each day for a selection of days in the week.
- Inventory: When Nick receives a shipment of green beans, they get placed in Inventory and available to allocate to his Roast Schedule.
Unlimited space
Whether or not we find ourselves running out of space, we want to avoid even the perception that there is a limited space on our Modeling Surface. As soon as the Team sees the potential for running out of room on their initial paper, they add as much additional space as they can…
I will be releasing most of this content only to subscribers. Make sure you sign up by clicking the big red button!
Related Posts:
- 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