Bounded Context Canvas V2: Simplifications and Additions

Nick Tune
Nick Tune
Jan 12 · 4 min read

Six months ago I wrote about the Bounded Context Canvas. In the six months since I’ve received feedback from my own workshops and other people’s workshops about ways to improve the canvas.

Here is V2 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.

The Bounded Context Canvas V2

In the remainder of this article I’ll explain what has changed and why.

If you prefer to learn the Bounded Context Canvas in a group setting, you can attend my workshop at the upcoming Domain-Driven Design Europe conference.

Strategic Classification

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

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.

Information and Services Provided

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

Dependencies and Relationship

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.

Have Fun Modelling and Innovating

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.

Nick Tune’s Tech Strategy Blog

Domain-Driven Design, Organisation Design, Continuous Discovery and Delivery, Technical Strategy…

Nick Tune

Written by

Nick Tune

Technical Leader | Sociotechnical Architect

Nick Tune’s Tech Strategy Blog

Domain-Driven Design, Organisation Design, Continuous Discovery and Delivery, Technical Strategy…

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade