The Bounded Context Canvas is a collaborative tool for designing and documenting the design of a single bounded context.
A bounded context is a sub-system in a software architecture aligned to a part of your domain.
The canvas guides you through the process of designing a bounded context by requiring you to consider and make choices about the key elements of its design, from naming to responsibilities, to its public interface and dependencies.
Download the blank canvas template.
To quickly get started with the Bounded Context Canvas, complete the canvas in the order the sections are presented in Section Definitions
Start with the name and description of the canvas to clarify its reason for existing and key responsibilities in a sentence or two. Then you can fill in the other sections of the canvas in any order. You could design outside-in starting with inbound communication or inside out starting with the business rules and domain language.
You may not have all the information you need to complete certain sections of the canvas. In such a case, you'll need to use other modelling techniques to find the information you require. See DDD Toolbox for suggestions.
Here is a short explanation of each section of the canvas.
Naming is hard. Writing down the name of your context and gaining agreement as a team will frame how you design the context.
A few sentences describing the why and what of the context in business language. No technical details here.
Writing down the description forces you to clearly articulate fuzzy thoughts and ensure everybody in the team is on the same page.
How important is this context to the success of your organisation?:
- core domain: a key strategic initiative
- supporting domain: necessary but not a differentiator
- generic: a common capability found in many domains
What role does the context play in your business model:
- revenue generator: people pay directly for this
- engagement creator: users like it but they don't pay for it
- compliance enforcer: protects your business reputation and existence
How evolved is the concept (see Wardley Maps):
- genesis: new unexplored domain
- custom built: companies are building their own versions
- product: off-the-shelf versions exist with differentiation
- commodity: highly-standardised versions exist
For detailed descriptions of genesis, custom built, product, and commodity see Wardley Maps Evolution definitions.
For help filling in this section of the canvas, see Core Domain Charts.
How can you characterise the behaviour of this bounded context? Does it receive high volumes of data and crunch them into insights - an analysis context? Or does it enforce a workflow - an execution context? Identifying the different roles a context plays can help to avoid coupling responsibilities.
Check out Alberto Brandolini's Bounded Context Archetypes and Rebecca Wirfs-Brock's Object Role Stereotypes for a deeper analysis of this space. The Model Traits worksheet contains community-generated examples of roles (model traits was the former name for domain roles).
Inbound communication represents collaborations that are initiated by other collaborators.
Messages are the information that one collaborator sends to be another. There are three types of conversation that can occur between bounded contexts. A request to do something (a command), a request for some information (a query), or notification that something has happened (an event).
The word message is used in the general sense and not tied to any implementation. No message bus or asynchronous workflow is obligatory. A command, for example, could simply be posting data from an HTML form as a HTTP POST command.
Collaborators are other systems or sub-systems that send messages to this context. They can be other bounded contexts, frontends (web or mobile), or something else.
If the Bounded Context owns the user interface (e.g. micro-frontend) then the collaborator type is direct user interaction.
The relationship type between two bounded contexts indicates how the models and teams influence each other. See Context Mappping to learn about relationship types.
Collaborators can be organised into horizontal swim lanes showing the messages that they send.
Outbound communication represents collaborations that are initiated by this context to interact with other collaborators. The same message types and notations apply as inbound communication.
What are the key domain terms that exist within this context, and what do they mean?
What are the key business rules and policies within this context?
Here are some tools that can help you to use the Bounded Context Canvas.
A HTML version of the canvas you can edit in a browser and version in source control alongside your code. Contributed by Nelson da Costa.
A free MiroHQ template of the Bounded Context Canvas.
A draw.io template of the canvas containing the Bounded Context Canvas as template.
By making the important elements of a bounded context's design visible on the canvas, you can more easily challenge and improve the design. Here are some tips help you challenge and improve a design.
Please feel free to create a Pull Request sharing your tips.
- Experiment by moving something on the canvas to another context. How is the design affected?
The public interface of a bounded context is its contract with the rest of the system. Contracts have a big impact on collaborators and are hard to change, so good design is vital. Here are some tips to help you critique the design of a bounded context's interface.
- Are the names of messages coherent with each other and the description of the context?
- Is each message type optimal (e.g. should a command be an event)?
- Is the interface too big (too many unique message types)?
- Is the context exposing too much of its internals?
- Do any messages seem like they should belong elsewhere?
Thank you to all existing and future contributors and to the following individuals who have all contributed to the Bounded Context Canvas:
A significant contribution to the Bounded Context Canvas was the inspiration of the Business Model Canvas.
The Bounded Context Canvas is freely available for you to use. In addition, your feedback and ideas are welcome to improve the canvas or to create new versions.
Feel free to also send us a pull request with your examples.
This work is licensed under a Creative Commons Attribution 4.0 International License.
