#29 From Chaos to Order: Bounded Context Canvas Explained
For years, I struggled to effectively describe bounded contexts. It was a constant challenge in my work, and I experimented with various methods, searching for the perfect fit. Finally, I found it.
What I (and my teams) used to struggle the most when doing strategic Domain-Driven Design was always the definition of the bounded context. First, what it is (I described it in this article). Second, how to describe it. In this post, we will look at the latter.
All notes were split into various locations. It wasn’t easy to find out what is triggering such a bounded context and what it triggers. The common (ubiquitous) language was defined somewhere else. Business rules? Yeah, again, somewhere else.
I started looking for a solution that fit our needs. I tried different ways and techniques. Finally, I found pure gold. DDD Crew introduced a canvas called Bounded Context Canvas.
This canvas helped us many times. Not only with the description but quite often, we discovered that this bounded context makes no sense. So, we either dropped it or merged it with another one.
The Name field is quite apparent. It represents the name of the bounded context.
Next to it, you can find the Purpose, one of my favorite fields because it forces people to justify why this context is needed. This is where you need to sit down for a while and think about why you need this bounded context. It is incredible how, in many cases, this is an eye-opener, and it turns out to be unnecessary altogether.
Then, there is the Strategic Classification field. It consists of three parts. First, we need to specify the type of domain:
Core
Description: The central part of your business, the key from the strategic perspective. It is where the primary business value (ROI) is created and is often the reason why customers choose your product or service over others.
Characteristics: It is unique to your business and requires internal development to meet specific business needs. It is complex, frequently evolving, and needs continuous refinement and innovation.
Focus: Highest priority in terms of resources and attention.
Supporting
Description: It is necessary for the business but does not constitute its competitive advantage. It supports the core ones but isn’t the primary focus of the business.
Characteristics: Less complex than the core, these areas still require specific business logic but are not as critical for the unique selling proposition of the product or service.
Focus: Often developed in-house but can be as well outsourced.
Generic
Description: It represents common areas across many businesses and indus- tries. They don’t provide a competitive advantage and are not specific to the business, like payment gateway or invoice creation.
Characteristics: These are often standardized processes or features with well- established solutions in the market.
Focus: Businesses opt for off-the-shelf solutions.
This knowledge lets you decide whether your bounded context is core, supporting, or generic.
Next, there is the Business Model field. To decide on a model, you need to answer several questions:
Does it directly generate revenue?
Is it the primary reason customers use your application?
Does it enhance your business reputation?
Does it primarily reduce costs?
Then, it’s time for the definition of the Evolution. You define it based on the Wardley Maps definitions. There are four of them:
Genesis. The market is undefined, and there is a lot of uncertainty. It constantly changes, but it has a high future worth.
Custom. There is already some expert knowledge in the area, so it is possible to learn from others. Still, there are many explanation models and no common understanding.
Product. Leveraging it becomes common; the knowledge is structured and focuses on improvements. You can find some off-the-shelf solutions that compete with each other.
Commodity. It is the new “standard”. There is a common understanding; it is stable and believed to be well-defined.
Next, there is the Domain Roles field. Here, you define the role of your bounded context inside the domain. It includes the following roles:
Analysis. Receive data, analyze, and provide insights about it.
Enforcer. Ensure that other contexts comply with procedures like anti-money
laundering.
Funnel. Receive data from other contexts, rework, and pass it further.
Execution. Trigger workflows and other bounded contexts.
Engagement. Provide features that attract customers to use your product
And others, which you can find, for example, here.
We move to another part of the canvas, the central one. On the left side, there is the Inbound Communication area. It defines who communicates with the bounded context (collaborators). It can be one of the below ones:
Another bounded context
External system
Frontend application
User (direct interaction)
Additionally, you need to define the way to communicate with the selected bounded context:
Query. Ask the bounded context for some information. For example, Get treatment plan details or Get available drugs.
Command. Order the bounded context to do something (change the state). For example, Review treatment plan or Confirm appointment.
Event. Inform the bounded context about some business event. For example, Appointment scheduled or Treatment completed.
The central part of the canvas is Ubiquitous Language and Business Decisions. For the first one, we collect terms that are specific within this bounded context and their definitions:
Risk Profile. It shows how much financial risk a person or company is okay with taking. It looks at their money goals and how they feel about possibly losing money.
Credit Risk. The chance that someone who borrows money might not pay it back. We figure this out by looking at things like if they have paid back loans before and how much money they have.
The Business Decisions field contains all business rules and policies inside the bounded context, like Each late payment reduces the credit risk score by 5 points.
The Outbound Communication area is defined in the same way as Inbound Communication.
At the bottom level of the canvas, you write:
Assumptions. You will always make some assumptions as it is impossible to have clear answers for everything. This is the place to write them.
Verification Metrics. How would you verify that defined boundaries are correct? These metrics can indicate if the bounded context is triggered too often or if its changes cause issues in other bounded contexts.
Open Questions. All the questions you could not clarify while defining bounded context.
At the end, you should get a similar result to this one:
Of course, there will be more business decisions, and new terms will extend ubiquitous language. Additionally, adding a short explanation, e.g., Risk Profile or Credit Risk, makes sense to clarify it for everyone.
What you can also do is put swim lanes inside the central part of the bounded context to isolate processes from each other, like here:
If you want to learn more about domain analysis and how to translate the results of Event Storming workshops into subdomains and bounded contexts, define context maps, and more, I invite you to look at my book.
Have you ever used this canvas? How do you deal with descriptions of bounded contexts?