Domain Discoveries
Once Nick describes the important Domain Events that he envisions for managing his own Inventory and Roast Schedule concepts, we start to focus on the Customer Experience of buying roasted coffee from him.
Nick and the Team imagine the Roast Schedule as a centerpiece of the site; the first thing that the Existing Customer/Potential Customer sees when they access firstpopcoffee.com.
If the Customer is interested in buying Coffee (I’m capitalizing key Ubiquitous Language terms also), they will likely choose a Roast Day from Nick’s Roast Schedule. The Domain Event is Roast Day Chosen.
What makes this domain more complex than a simple “Add a Product to a Cart and Checkout” is that we are “Auctioning Off” a Product that will have a finite Available Quantity allocated to a single Roast Day. It’ll be similar to a Venue with limited Available Seating. This means that the potential Customer can’t leave Product in their Cart without making a decision within, say 5 minutes. They need to allow other Potential Customers a chance to actually buy the Coffee that’s available on that Roast Day.
Nick and the Team start putting new Domain Events up on the wall. Nick is in the mindset that he’s going to “roast the green beans according to his available inventory and schedule he designed”. So he starts putting Events up like Roast Day Green Bean Quantity Reserved and Reserved Green Beans Un-Reserved. A purple stickie goes up: “When do ‘Green Beans’ cease being ‘Green Beans’ and become ‘Roasted Coffee for Sale’?”…
This thought process tugs at the core of Domain-Driven Design. Does the Potential Customer really care about Nick’s inventory of Green Beans and how he is managing his Roast Schedule outside of simply wanting to buy fresh coffee beans? True, both the Customer and Nick have one focal point - the Roast Schedule. For Nick, he’s using the Roast Schedule to plan and control both the demand and supply for his roasted green coffee beans. For the Customer, they’re using the Roast Schedule to buy artisan-roasted coffee.
So the question was asked “When do the ‘Green Beans’ cease being ‘Green Beans’ and become ‘Roasted Coffee for Sale’?”… the answer is that they don’t. Customer and Roaster are two separate Bounded Contexts.
This is where Domain-Driven Design fixes traditional modeling. What is a core reason why we end up with unmanageable, spaghetti integrations…? We assume that a concept that lives in one context MUST live in another context.
While the Team notices this distinction, they decide to save the delineation of these Bounded Context for a “Design Level” EventStorming session later. They do, however help Nick to establish the different terms in the Ubiquitous Language as he continues putting more Events on the wall.
Revised Ubiquitous Language Glossary:
- Roasted Coffee: Roasted coffee that is purchased from firstpopcoffee.com. It is the end product of roasting the allocated Green Bean Inventory for a given Roast Day
- 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.
The Whole Picture
Nick and the Team continues, filling in all of the Domain Events that they can think of and come to agreements about. Questions arise that they have to discuss further like “Is Reserving the Coffee the same as adding the Coffee to your Cart?” After a little discussion, they determine that Roasted Coffee Quantity Added to Cart signifies the beginning of the Countdown Timer Started Event to give the Customer five minutes to order the Coffee.
We’re looking for a Big Picture of Nick’s business. This applies for any kind of business you want to use EventStorming for. This first session is an attempt to see everything that’s in everyone’s head about the business, to break down information “silos.”
I will be releasing most of this content only to subscribers. Make sure you sign up by clicking the big red button!
Related Posts:
- 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