The Bounded Context Canvas
The Bounded Context Canvas is a collaborative tool for designing and documenting the design of a single bounded context.
If you're not sure what a bounded context is you may want to check out Eric Evans DDD Reference and Martin Fowler's article.
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.
Summary
- How to Use
- Section Definition
- Example
- Tools
- Design Tips
- Additional Resources
- Translations
- Contributors
- Contributions and Feedback
How to Use
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.
Alternative Formats
The default Bounded Context Canvas format shown above is not the only format, below are others. Feel free to also experiment with new and novel formats.
- Use Case Swimlanes: This style organizes the communication section into swimlanes showing the sequence in which interactions occur using the format: message in -> decision(s) made -> message(s) out
Section Definitions
Here is a short explanation of each section of the canvas.
Name
Naming is hard. Writing down the name of your context and gaining agreement as a team will frame how you design the context.
Purpose
A few sentences describing the why and what of the context in business language. No technical details here.
Writing down the purpose forces you to clearly articulate fuzzy thoughts and ensure everybody in the team is on the same page.
Describe the purpose from a business perspective, you may also name key actors for whom the bounded context provides value.
Strategic Classification
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.
Domain Roles
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
Inbound communication represents collaborations that are initiated by other collaborators.
Messages
Messages are the information that one collaborator sends to 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
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.
Relationship Type
The relationship type between two bounded contexts indicates how the models and teams influence each other. See Context Mappping to learn about relationship types.
Organising Into Swimlanes
Collaborators can be organised into horizontal swim lanes showing the messages that they send.
Outbound Communication
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.
Ubiquitous Language
What are the key domain terms that exist within this context, and what do they mean?
Business Decisions
What are the key business rules and policies within this context?
Assumptions
You will never make design decisions having a full knowledge about everything in your domain. Most design happens based on assumptions and it is highly recommended to make them explicit. This can be done in this section of the Bounded Context Design Canvas.
Verification Metrics
Domain Driven Design is about an iterative approach towards modelling and design based on continuous learning. Metrics can help you gathering valuable input for those learnings (think about build-measure-learn). Think about metrics that you and your team can define in order to gather learnings if the chosen boundaries of your bounded context are a good fit or not.
You can collect those metrics for instance from:
- Your CI / CD environments
- Tools like JIRA
- From your live systems
Open Questions
If you have questions that no one in the room can answer while running a workshop you can enter them into this section of the canvas. This way you can make sure that no open questions get lost but you can also get a visual indicator how certain the team is regarding the design of a given bounded context. Many questions are a good indicator towards a high degree of uncertainty.
Example
Below a filled-in version of the Bounded Context Canvas.
Tools
Here are some tools that can help you to use the Bounded Context Canvas.
HTML Version
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.
Miro Version
A free MiroHQ template of the Bounded Context Canvas.
The current version of the template on Miroverse is v4 at the moment. In the meantime, you can download a Miro board backup here from this repository
draw.io Version
A draw.io template of the canvas containing the Bounded Context Canvas as template.
Excalidraw Version
A Excalidraw template of the canvas containing the Bounded Context Canvas as template.
Design Tips
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.
General Tips
- Experiment by moving something on the canvas to another context. How is the design affected?
Interface Design Tips
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?
Additional Resources
Translations
All resources are available in French and in Portuguese.
Contributors
Thanks 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.
Contributions and Feedback
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 or with new translations.
This work is licensed under a Creative Commons Attribution 4.0 International License.
