Bounded Context Canvas V3: Simplifications and Additions
This is an old post. You can find the latest version of the canvas on github: https://github.com/ddd-crew/bounded-context-canvas
Here is V3 of the canvas. Please feel free to use it, create remixes, or simply take it as inspiration to develop your own ways of designing bounded contexts. Whatever you do, I’d love to hear about it — I feel there is a lot of potential to improve how we design bounded contexts and this is just the starting point.
In the remainder of this article I’ll explain what has changed and why.
Strategic Classification
In the Strategic Classification section there are now some hints. In addition to just documenting if the context is core, supporting, or generic, the hints encourage you to understand the role of context in the business model, and to consider how the context’s value will evolve over time using Wardley Maps.
These hints are purely recommendations. You can add any information you want here to communicate the alignment with the business strategy. Personally, I do find these three to be the most useful.
Model Traits
Model Traits is a new section added to the canvas. The purpose of this section is to articulate the characteristics of this context’s domain model.
One common pattern in domains is to have separate models for plan, do, check. One type of context describes a job to be done, another performs the job, and another assesses the job once complete (Alberto Brandolini refers to them as Draft, Execute, and Audit, check out Cyrille Martraire’s blog post).
There are also standard traits defined in Enterprise Integration Patterns which can apply to bounded contexts.
At the moment, this section of the canvas is open to any type of label — whatever best conveys the essence of your bounded context’s internal behaviours and model type.
Messages Consumed and Produced
This section documents the public interface a bounded context. What does it receive and what does it produce. In DDD, we use three types of messages:
- Command: the producer instructs the recipient to do something. A command can fail.
- Domain Event: a significant event in the domain which happened inside a single bounded context which other bounded contexts may need to know about or respond to. Unlike a command, there is no obligation of when or how to respond to an event.
- Query: one contexts request information from another, or more abstractly asks a question.
Dependencies and Relationships
The dependencies section has been broken down into two groups — other bounded contexts whose messages come in (message suppliers) and other bounded context who consume messages coming out (message consumers).
The relationships column is a free text field. Maybe we will refine the language and add structure here over the coming years.
Have Fun Modelling and Innovating
In addition to my own modelling sessions, I’ve been contacted by a number of people who found the canvas to be useful, giving them a structured technique to follow for designing bounded contexts. If you want to improve how your team practices Strategic DDD, I think you too will find it to be useful.
More importantly, keep looking for better ways to design systems. Feel free to change the canvas or create an entirely new one. The canvas itself is originally based on a questionnaire I used to use so maybe there is a way to re-design some of your existing processes.
The changes outlined in this post were based on real feedback and I hope more feedback in the future can further improve the technique’s value and simplify it’s usage. Your constructive feedback and suggestions are definitely welcome.
Version 2 (Superseded Amendments)
Information and Services Provided
This section has been renamed to make it clearer that the goal is to document the public interface of the context. Anything that other contexts can consume, and importantly, become coupled to, belongs here.
In addition, four hints have been added to make it clearer what types of information go here and where they live.
- Queryable Information: what information can other contexts query from this context? What questions can they ask?
- Invokable Commands: what commands can other contexts invoke on this context? What can they tell it to do?
- Published Events: what events does this context publish publicly that other contexts can subscribe to?
- Reactive Jobs: what jobs does this context perform which are initiated internally — e.g. scheduled jobs, or kicking off a business process when responding to an event published by another context (strictly speaking this isn’t part of the public interface, but it seems useful to add it here).
Dependencies and Relationships
The name of this section has been updated to include relationships. Not only are they dependencies but the relationship — the reason for the dependency — is a semantic we want to emphasise.
More importantly, this section has a new layout. It has been broken down into suppliers and consumers. Who supplies this context with information and services (via events, queries, and commands), and who consumes this context’s information and services?
There is still no prescribed format for the relationship column. This is deliberate. To begin with, start with a simple phrase e.g. “provides delivery tracking updates via events”. Later as you start to introduce more advanced concepts like DDD’s Relationship Patterns or Team Topologies’ Interaction Modes, they can instead be used here.
