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.
There is no strict rule about the order in which you should fill out the canvas, however, in general it is recommended to start at the top left with the name, move down the left column and then start at the top of the right column.
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
What are the key business rules and policies within this context?
What are the key domain terms that exist within this context, and what do they mean?
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.
Think about the best way to describe your context's behaviour, but do not specify architectural patterns here.
Check out Model Traits worksheet or Alberto Brandolini's ideas for inspiration.
What is the public interface or the contract of your bounded context? Which messages come in and which does it send out?
To create loosely coupled systems it's essential to be wary of dependencies. In this section you should write the name of each dependency and a short explanation of why the dependency exists.
Thank you 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.
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent