The Event Storming workshop went great. Not only you have explored Mr. Sandwich’s Domains, but you have also distilled Bounded Contexts. Told you, you might be surprised. This time, they perfectly match Bounded Contexts, because project is not too complex or significantly huge. It is important to keep in mind, that this is not a norm, or something you have to achieve at all costs. Back to Contexts, what are they exactly?
Defining Bounded Contexts
Let’s go through Domains and Contexts:
-
Food Factory — our Core Domain and Bounded Context at the same time. It has its own business boundaries and rules on a food producing level. All other Contexts and Domains are basically build around producing and selling food.
-
Web Store — the Generic Domain, it improves selling process, but also helps to prevent wasting of food. This is the problem you have managed to solve, and another functionality your client wants. More work means more money, it will make your boss happy. This Bounded Context relies on Food Factory, which is the only source of truth about Dishes being actually sold.
-
Delivery — this is the Supporting Domain, which brings a great value to Mr. Sandwich’s service. Customers don’t have to go anywhere, their food will be delivered straight to their workplace, same time, everyday. Delivery, which is also a perfect Bounded Context, relies on Web Store and Orders placed there by the Customer.
Preparing Context Map
The next step, is to define a Context Map, this will be a summary of the Strategic Domain-Driven Design phase and clear guide how teams will cooperate during works on Microservices assigned to them.
Summary
As you can see on the Context Map above, Bounded Contexts are loosely coupled, this is a comfortable situation. Teams will only have to publish a REST APIs for their Microservices, it will definitely shorten the time needed for development.