Complexity and Cost
The Team goes back and asks Nick (*and themselves) what the Complexity/Cost is associated with implementing a custom, automated system around a Bounded Context…
Team: How much Complexity/Cost would there be to automate the management of Nick’s Green Bean Inventory?
Nick: I only need to make sure I’m not out of Green Beans and I know what kind of Coffee I have on hand.
Team: Let’s say Medium, we can likely do this with CRUD. It’ll probably need to handle Events from the Roast Execution Bounded Context to decrease inventory where appropriate. That’s the most complexity we’re looking at. Small.
Team: How much Complexity/Cost would there be to automate Nick’s Roast Planning?
Nick: This is important for me, it’s Core to me being able to scale my roasting efforts from week to week. It’s Core to making sure my Customers know what’s available for them to buy.
Team: We’re managing a lot of state here - State of a Roast Day, State of the Available Coffee Quantities within the Roast Schedule, Various Quantities Allocated to the Customers, Level of Roast Schedule Completion. It’ll be fairly complex to make sure the moving parts work well in this Bounded Context. Let’s say Large.
Team: How much Complexity/Cost would there be to automate the management of Nick’s Roast Execution?
Nick: I need to be able to keep myself on track and manage my time well during the roast day process. I don’t want to be roasting more than I should, I don’t want to be roasting for 12 hrs a day when I don’t need to so I need to have a clear plan that I can follow. It’ll also be nice to know who I’m roasting for, I want to have that connection with my customers.
Team: There’s some state going on with the Roast Execution as well - Nick starts the Roast Day, the Green Beans allocated to the Roast Day will be roasted. There will be communication with the Customer and via the public website about Nick’s progress through the roast day. Large.
Team: How much Complexity/Cost would there be to automate Order Fulfillment?
Nick: I can handle Order Fulfillment manually to some extent. It’s just a matter of keeping myself on track and knowing how I need to package up, ship, and label the coffee when I’m done roasting.
Team: Yea there’s 3rd party options we might want to look at here. Nick’s Roast Planning and Roast Execution are more unique to his business than fulfilling orders… lots of physical product businesses have to handle order fulfillment, we probably don’t need to reinvent the wheel here. Medium.
Team: How much Complexity/Cost would there be to automate Coffee Sales?
Nick: This is the public facing part of my site. This tells the Customer what I’m all about and it’s unique to my business. It’s also how I publish my roast schedule and update/change what’s available to buy from each roast day.
Team: Yea this is going to be more complex. While actually checking out of the cart may be something we do with a 3rd party as we go, the choosing of coffee and reserving the roast day quantity with the 5 minute timeout will be complex, let’s say Large.
Team: How much Complexity/Cost would there be to implement User Management?
Nick: I don’t know much about this, but it’s pretty much a default on every fancy coffee sales site I’ve seen.
Team: We don’t need to reinvent the wheel. It doesn’t contribute to Nick’s Competitive Advantage. We can do as much of this with 3rd party authentication solutions as we can. Small.
| Bounded Context | Competitive Advantage | Complexity/Cost |
|---|---|---|
| Green Bean Inventory | M | S |
| Roast Planning | L | L |
| Roast Execution | L | L |
| Order Fulfillment | S | M |
| Coffee Sales | L | L |
| User Management | M | S |
The Coffee Sales Bounded Context is a little bit fuzzy, the Team finds during their discussion. How much of the Coffee Sales is Shopping Cart management and how much is Roast Day Quantity Reservation management? They need to move on, but this will stay in the back of their minds as they start their implementation.
What the Team was looking for in this quick analysis is those Bounded Contexts with Large Competitive Advantage and Large Complexity/Cost:
- Roast Planning
- Roast Execution
- Coffee Sales
These Bounded Contexts are going to be the focus when applying Domain-Driven Design. From the onset, in Nick’s best interest, the Team wanted to make sure they are customizing and working on a good Domain Model for those Bounded Contexts that will be complex and have a huge impact on generating value for Nick. EventStorming helped identify those quickly.
I will be releasing most of this content only to subscribers. Make sure you sign up by clicking the big red button!
Related Posts:
- Design Level EventStorming
- 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