szpak
Back to tutorials

Defining Bounded Contexts

Learn by example how to define Bounded Contexts for Mr. Sandwich.

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 still need explicit integration contracts for their Microservices. REST APIs may be enough for some interactions, while events or other protocols may fit better elsewhere. Clear contracts shorten development more reliably than any single communication style.