Skip to content
Software Architecture Guide

Bounded Context Canvas

Explanation

Section titled “Explanation”

A bounded context is one area of a system with its own clear model and boundaries (see the article Bounded Context). The Bounded Context Canvas helps a team design and document exactly one such context. The team works on it together (f1).

The canvas has several sections. These are the ones covered here.

Name. The team writes down the context’s name and agrees on it. The name frames how the team designs the context.

Purpose. A few sentences explain why the context exists and what it does. They use business language and contain no technical details.

Strategic classification. This asks how important the context is to the organization: core, supporting, or generic. The canvas also covers the business model and how far the context has evolved, from genesis through custom built and product to commodity.

Domain roles. This section describes how the context behaves, for example in analysis or execution roles. Two examples:

  • A specification (or draft) role produces a document that describes a job or request to be performed.
  • A gateway role sits at the edge of the system. It manages inbound and/or outbound communication.

Assumptions. Nobody designs with full knowledge of the domain. This section gives the team a place to record what it is assuming.

Verification metrics. These rest on the idea that domain-driven design (see Domain-Driven Design) is iterative and based on continuous learning.

Open questions. Many open questions signal high uncertainty in the design.

Example

Section titled “Example”

A team documents an “Order Fulfillment” context. They agree on the name first. The purpose reads: “Make sure every paid order reaches the customer on time.” They classify it as core, because it matters to the company’s success. They give it a gateway role for the messages it sends and receives. They list assumptions, such as “carriers deliver within three days,” and several open questions. The long question list tells them the design is still uncertain.

Trade-offs

Section titled “Trade-offs”

The canvas covers one context at a time. It does not show how contexts relate to each other. The facts here say nothing on that point. A long list of open questions is not a flaw in the canvas. It is a useful signal of uncertainty. Keeping the purpose free of technical detail keeps it readable for business people. Technical design has to be recorded elsewhere.

Checks

Section titled “Checks”
  • The purpose of each bounded context is stated in a few sentences of business language, without technical details.
  • The team has agreed on the name of each bounded context.
  • Each bounded context is classified as core, supporting, or generic.
  • Assumptions and open questions are written down, and many open questions are treated as a sign of high uncertainty.
Section titled “Related”

Sources

Section titled “Sources”