Modelling Bounded Contexts with the Bounded Context Canvas: A Workshop Recipe
After reading this post, check out a more recent post: Bounded Context Canvas V2
How do we break a large system into smaller, more manageable modular components? This is the question I get asked the most, so I’ve put together this article describing a workshop recipe you can use.
In Domain-Driven Design, a large system is decomposed into bounded contexts, which become natural boundaries in code as microservices and as teams in the organisation.
There is no shortcut to identifying good boundaries. Both a wide and deep knowledge of the business and domain is essential. This workshop format is designed around both of these needs and uses two tools in order to find the most effective system design: EventStorming and the Bounded Context Canvas.
I designed this canvas based on the typical flow of strategic DDD workshops I run publicly and privately. But don’t hesitate to tweak the structure if you find a format that works better for you.
The Recipe
The basic recipe is composed of the following activities:
- Big Picture EventStorming (min. 1 hour)
- Candidate Context Modelling (min. 30 minutes)
- Domain Message Flow Modelling (min. 30 minutes)
- Bounded Context Canvas (min. 90 minutes)
- Refined Context Exploration (min. 45 minutes)
I recommend allocating a full-day for this workshop as a starting point. This will help you to understand how much time you actually need to do it properly. If you only have one chance to get everybody together, try and allocate two days.
Ideally attendees will be a mixture of domain experts and technical experts. If that is hard to achieve at-least try to have your domain experts available for the first hour.
Modelling Fundamentals Recap
You need a lot of space for this workshop. If all you can get is a cramped up boardroom, you’re going to be disappointed with the results. Each group of four people will need at-least four metres of wall space
I’ve presented the techniques loosely in order that you might want to follow them. However, keep in mind :
We are constantly switching between problem space and solution space. We look for information, create a model, look for more information, refine the model, etc.
One final point to remember: the goal of the workshop is to produce options and develop the ability to product better options in the future.
1. EventStorming
If you want to design systems, you need two things: a big enough overview of the whole system and deep enough details of each area. For this purpose, we start with EventStorming.
EventStorming is a collaborative modelling technique for modelling a large problem domain from end-to-end, whilst also being able to drill down into as much details where needed.
If it’s your first time, I recommend allowing between 1–2 hours for EventStorming.
Upon completion of EventStorming, I recommend you split the group into teams of up to 4 people.
2. Candidate Context Discovery
With your domain modelled wide and deep as an EventStorm, you can then begin to group and organise the pieces into bounded contexts.
There are a variety of techniques you can use to start identifying bounded contexts. My preferred techniques for getting started are:
- Start with value — identify the core parts of the domain which have the highest value to the business.
- Start with simple — create the simple-but-naive model by breaking up the timeline into sequential steps.
- Look for pivotal events — look for key business events which indicate state changes between different parts of the business process.
Spend no more than 30 minutes on this task initially. Encourage the group to create an initial model of bounded contexts as a starting point. It doesn’t need to be perfect and it’s unlikely to be the final solution.
The output should simply be a list of bounded context names as post-its on the wall or written on paper. You can’t physically modify the EventStorm if there are multiple groups.
Iterating From Here
You may immediately identify multiple possible ways to model the system. For now, choose one to work with and make a note of the other possible models (they will be useful later). You may also realise that you are lacking domain information. If so, consider doing another round of EventStorming.
3. Domain Message Flow Modelling
One way to test the validity of your design and gain feedback on how to improve the design is to visualise how bounded contexts must collaborate to solve full business use cases for users of the system.
If the domain flow is complex with many dependencies and bi-directional relationships, for example, it’s a warning that your design is fragile and needs further analysis.
There are a variety of visualisation techniques you can use to model flows and use cases including UML sequence diagrams and UML use case diagrams. I prefer to use a variant of domain storytelling.
With Domain Message Flow Modelling, the bounded contexts themselves are the actors in the story. So a typical story begins with a user trying to achieve a goal, followed by the interaction between bounded contexts in order to provide the user with a solution to their goal.
Modelling strategic domain flows gives you feedback on your proposed bounded contexts. It shows how the collaborate together and depend on each other to carry out full business use cases. This guides you into exploring alternative design opportunities.
One question you can ask yourself is: does the description of each bounded context align with the role it plays in the domain flow? If not, it’s likely that naming or boundaries require redesign.
Iterating From Here
As your domain flows identify relationships between bounded contexts you may immediately uncover obvious design flaws or missing capabilities. You are free to return to the previous activity and update your candidate contexts or perform a second iteration of EventStorming.
You can also make a note of your design feedback and gather more information from subsequent activities before beginning your redesign.
4. Bounded Context Canvas
The next step of the design process is to design your candidate bounded contexts by detailing key design criteria.
In your team choose what you feel is the most important bounded context. Limit this activity to 3 minutes maximum. It’s not critical to be 100% accurate.
Now, draw a Bounded Context Canvas and work through the following steps to fill in the details. I recommend using 1 sheet of a flip chart or similar size paper.
Once you complete the following steps, repeat the process until you have defined all of your bounded contexts. Try to approximately divide your time equally between the number of candidate bounded contexts you identified.
4.1 Context Overview Definition
Begin by filling in the name of your bounded context and a description. The description should describe the purpose the context plays in the domain and it’s role in the business, not implementation details.
Next, determine the strategic classification. Is the bounded context a core part of the system, a supportive piece, generic, or something else? Read Vladik’s post if you need help choosing.
Iterating From Here
Treat it as design feedback when you cannot think of a clear name or write a cohesive, precise description, or your UL terms are ambiguous. Consider redesigning the boundaries now, or make a note and return later (usually better to return later).
4.2 Business Rule Distillation & Ubiquitous Language Capture
Now refer back to the EventStorm and look at the sticky notes you recorded for this bounded context. Look for the most important business rules or policies — try to select the top 3 and add them to the canvas.
This is also a good time to look for key business words or phrases add them to the canvas in the Ubiquitous Language section. You will continue to add words and phrases throughout the workshop, this is just a starting point.
4.3 Capability Analysis
Accentuating the capabilities provided by the bounded context is the next priority. Not only does this clarify what a bounded context does, it also provides a wealth of design feedback. You can start asking questions like:
- Does this context have too many responsibilities?
- Do the capabilities seem cohesive?
- Do the capabilities logically align with the name and description?
- What if we moved this capability outside of the context?
Begin identifying capabilities by envisioning the public interface. What queries can consumers ask of this bounded context and what commands can they invoke? User your domain flow stories here to see what consumers need from this context.
Not all capabilities are externally-activated commands and queries. Some capabilities can be triggered internally, for example scheduled tasks so think about these too.
Sometimes you’ll notice that capabilities cluster, like a command, a query, and a notification. If so, cluster them together on your canvas and give the cluster a name.
Often you will have a feeling that a responsibility is misplaced and should belong to a bounded context. If so, highlight with a small yellow sticky or put a red dot on the post-it.
Iterating From Here
If you’re struggling to identify many capabilities or you feel some are missing I recommend you return to your EventStorm and model this bounded context in more detail with a specific outside-in focus looking for capabilities required by other contexts/services.
Capability Layering [Optional]
Decompose each capability on your canvas into sub-capabilities. This additional granularity gives you more pieces to play with increasing your ability to find alternative models.
There’s usually no space on the canvas. So find another sheet of paper or wall space. You can go as many layers deep as you feel beneficial.
4.4 Dependencies
Dependencies are essential if we want modularity, but dependencies cause a wide range of business, technical, and social problems. It’s, therefore, essential to discern dependencies, understand their impact, and consider alternative choices.
So the final section of the Bounded Context Design encourages you to capture the key dependencies of your bounded context.
Looking at your EventStorm and domain flow diagrams, identify each dependency your bounded has and note the following information:
- name of the other bounded context or service
- a brief sentence explaining why the dependency exists
- where the dependency resides: internal to this system or in an external system (e.g. a 3rd party service)
- the type of relationship: is it an incoming dependency (the other service depends on this bounded context), outgoing (this bounded context depends on the other), bidirectional, or UI (the dependency is some type of user interface)
As you’re doing this, challenge each dependency. Is the dependency necessary? What are the costs and benefits of the dependency. If you think a dependency could be avoided, mark it with a small yellow post-it.
4.5 Design Critique
Now that you have completed the, canvas spend a few minutes in your team critiquing the design of your bounded context. Organise your feedback into the following categories:
- Good: aspects of the design you like
- Bad: aspects of you the design you dislike
- Unsure: aspects of the design you are unsure about
4.6 Reflect and Iterate
Good design is iterative. Before moving onto the next bounded context, step back and look at the big picture view. Have you learned anything that challenges your design? If you have, re-shape your proposed boundaries now and then continue designing the next bounded context.
At this point, ask yourself if you have modelled the domain in enough detail. Were you struggling to complete sections of your canvas? If so, consider another round of EventStorming across the whole domain or just in certain parts of the domain.
5. Refined Exploration
After creating a canvas for each bounded context and collecting lists of design feedback, the next part of the workshop is a return to exploration. This time, you have a highly-refined body of knowledge to help you explore better design options.
The output of this activity is a collection of basic context maps — visualisations of the structural relationship between bounded contexts, and any other diagrams you feel necessary like domain flow stories. Each team should produce at-least three context maps, each showing alternative possible designs of the system.
- The final activity is fairly freeform. The goal is to review all of the information collected and use it to product multiple designs. As a starting point, I recommend:
- Reviewing all the feedback collected for each context and experimenting with the “bad” and “unsure” feedback
- Asking “what if” questions…
- “What if we move this capability to another bounded context?”
- “What if we break up this capability and move one of the sub-capabilities to another bounded context?”
- “What if we split the bounded context into multiple contexts?”
- “What if we take a capability from each of these 3 contexts and use it form a new context?”
- “What if we duplicate functionality to break a dependency?”
- “What if we create a shared service to reduce duplication across multiple contexts?”
- “What if we isolate the truly core capabilities and move the others into a separate context?”
If you prefer a visualisation of these transformations you may find the following useful:
5. Closing Presentation
To close out the workshop each group should present a selection of the context maps they created and discuss the trade-offs of each design. They should explain their preferred choice and why.
A presentation of between 5 and 10 minutes is usually sufficient.
Things to consider in a presentation:
- Focus on the core domains: how does each design enable the core parts of the system to be developed more effectively?
- Compare domain flow stories: how did one system design reduce complexity and number of dependencies.
- Explain what you will do next to validate your preferred choice
Training and Consulting
If you are seeking help exploring your domain, designing your system, or training your teams, contact me for further information. I work with a network of highly-experienced DDD practitioners who are passionate about designing effective sociotechnical systems aligned with the business goals and domain.
