Modelling Bounded Contexts with the Bounded Context Canvas: A Workshop Recipe

Nick Tune
Nick Tune
Jul 22, 2019 · 11 min read

After reading this post, check out a more recent post: Bounded Context Canvas V2

How do we break a large system into smaller, more manageable modular components? This is the question I get asked the most, so I’ve put together this article describing a workshop recipe you can use.

In Domain-Driven Design, a large system is decomposed into bounded contexts, which become natural boundaries in code as microservices and as teams in the organisation.

There is no shortcut to identifying good boundaries. Both a wide and deep knowledge of the business and domain is essential. This workshop format is designed around both of these needs and uses two tools in order to find the most effective system design: EventStorming and the Bounded Context Canvas.

Image for post
Image for post
The Bounded Context Canvas

I designed this canvas based on the typical flow of strategic DDD workshops I run publicly and privately. But don’t hesitate to tweak the structure if you find a format that works better for you.

The Recipe

  • Big Picture EventStorming (min. 1 hour)
  • Candidate Context Modelling (min. 30 minutes)
  • Domain Message Flow Modelling (min. 30 minutes)
  • Bounded Context Canvas (min. 90 minutes)
  • Refined Context Exploration (min. 45 minutes)

I recommend allocating a full-day for this workshop as a starting point. This will help you to understand how much time you actually need to do it properly. If you only have one chance to get everybody together, try and allocate two days.

Ideally attendees will be a mixture of domain experts and technical experts. If that is hard to achieve at-least try to have your domain experts available for the first hour.

Modelling Fundamentals Recap

I’ve presented the techniques loosely in order that you might want to follow them. However, keep in mind :

We are constantly switching between problem space and solution space. We look for information, create a model, look for more information, refine the model, etc.

One final point to remember: the goal of the workshop is to produce options and develop the ability to product better options in the future.

1. EventStorming

EventStorming is a collaborative modelling technique for modelling a large problem domain from end-to-end, whilst also being able to drill down into as much details where needed.

Image for post
Image for post
EventStorming looks fun and is fun.

If it’s your first time, I recommend allowing between 1–2 hours for EventStorming.

Upon completion of EventStorming, I recommend you split the group into teams of up to 4 people.

2. Candidate Context Discovery

Image for post
Image for post
Finding bounded contexts on an EventStorm. Credit: Alberto Brandolini

There are a variety of techniques you can use to start identifying bounded contexts. My preferred techniques for getting started are:

  • Start with value — identify the core parts of the domain which have the highest value to the business.
  • Start with simple — create the simple-but-naive model by breaking up the timeline into sequential steps.
  • Look for pivotal events — look for key business events which indicate state changes between different parts of the business process.

Spend no more than 30 minutes on this task initially. Encourage the group to create an initial model of bounded contexts as a starting point. It doesn’t need to be perfect and it’s unlikely to be the final solution.

The output should simply be a list of bounded context names as post-its on the wall or written on paper. You can’t physically modify the EventStorm if there are multiple groups.

Iterating From Here

3. Domain Message Flow Modelling

If the domain flow is complex with many dependencies and bi-directional relationships, for example, it’s a warning that your design is fragile and needs further analysis.

There are a variety of visualisation techniques you can use to model flows and use cases including UML sequence diagrams and UML use case diagrams. I prefer to use a variant of domain storytelling.

With Domain Message Flow Modelling, the bounded contexts themselves are the actors in the story. So a typical story begins with a user trying to achieve a goal, followed by the interaction between bounded contexts in order to provide the user with a solution to their goal.

Image for post
Image for post
Example domain message flow not based on any reality or company

Modelling strategic domain flows gives you feedback on your proposed bounded contexts. It shows how the collaborate together and depend on each other to carry out full business use cases. This guides you into exploring alternative design opportunities.

One question you can ask yourself is: does the description of each bounded context align with the role it plays in the domain flow? If not, it’s likely that naming or boundaries require redesign.

Iterating From Here

You can also make a note of your design feedback and gather more information from subsequent activities before beginning your redesign.

4. Bounded Context Canvas

In your team choose what you feel is the most important bounded context. Limit this activity to 3 minutes maximum. It’s not critical to be 100% accurate.

Now, draw a Bounded Context Canvas and work through the following steps to fill in the details. I recommend using 1 sheet of a flip chart or similar size paper.

Once you complete the following steps, repeat the process until you have defined all of your bounded contexts. Try to approximately divide your time equally between the number of candidate bounded contexts you identified.

4.1 Context Overview Definition

Next, determine the strategic classification. Is the bounded context a core part of the system, a supportive piece, generic, or something else? Read Vladik’s post if you need help choosing.

Image for post
Image for post
An example Bounded Context Canvas after Activity 1 (note: this is a purely fictional domain; any likenesses are unintended)

Iterating From Here

4.2 Business Rule Distillation & Ubiquitous Language Capture

This is also a good time to look for key business words or phrases add them to the canvas in the Ubiquitous Language section. You will continue to add words and phrases throughout the workshop, this is just a starting point.

Image for post
Image for post
An example Bounded Context Canvas after Activity 2 (note: this is a purely fictional domain; any likenesses are unintended)

4.3 Capability Analysis

  • Does this context have too many responsibilities?
  • Do the capabilities seem cohesive?
  • Do the capabilities logically align with the name and description?
  • What if we moved this capability outside of the context?

Begin identifying capabilities by envisioning the public interface. What queries can consumers ask of this bounded context and what commands can they invoke? User your domain flow stories here to see what consumers need from this context.

Not all capabilities are externally-activated commands and queries. Some capabilities can be triggered internally, for example scheduled tasks so think about these too.

Sometimes you’ll notice that capabilities cluster, like a command, a query, and a notification. If so, cluster them together on your canvas and give the cluster a name.

Often you will have a feeling that a responsibility is misplaced and should belong to a bounded context. If so, highlight with a small yellow sticky or put a red dot on the post-it.

Image for post
Image for post
An example Bounded Context Canvas after Activity 3 (note: this is a purely fictional domain; any likenesses are unintended)

Iterating From Here

Capability Layering [Optional]

There’s usually no space on the canvas. So find another sheet of paper or wall space. You can go as many layers deep as you feel beneficial.

4.4 Dependencies

So the final section of the Bounded Context Design encourages you to capture the key dependencies of your bounded context.

Looking at your EventStorm and domain flow diagrams, identify each dependency your bounded has and note the following information:

  • name of the other bounded context or service
  • a brief sentence explaining why the dependency exists
  • where the dependency resides: internal to this system or in an external system (e.g. a 3rd party service)
  • the type of relationship: is it an incoming dependency (the other service depends on this bounded context), outgoing (this bounded context depends on the other), bidirectional, or UI (the dependency is some type of user interface)

As you’re doing this, challenge each dependency. Is the dependency necessary? What are the costs and benefits of the dependency. If you think a dependency could be avoided, mark it with a small yellow post-it.

Image for post
Image for post
A complete Bounded Context Canvas (note: this is a purely fictional domain; any likenesses are unintended)

4.5 Design Critique

  • Good: aspects of the design you like
  • Bad: aspects of you the design you dislike
  • Unsure: aspects of the design you are unsure about

4.6 Reflect and Iterate

At this point, ask yourself if you have modelled the domain in enough detail. Were you struggling to complete sections of your canvas? If so, consider another round of EventStorming across the whole domain or just in certain parts of the domain.

5. Refined Exploration

The output of this activity is a collection of basic context maps — visualisations of the structural relationship between bounded contexts, and any other diagrams you feel necessary like domain flow stories. Each team should produce at-least three context maps, each showing alternative possible designs of the system.

Image for post
Image for post
A very lo-fidelty context map. For this workshop, this level of detail is sufficient.
  • The final activity is fairly freeform. The goal is to review all of the information collected and use it to product multiple designs. As a starting point, I recommend:
  • Reviewing all the feedback collected for each context and experimenting with the “bad” and “unsure” feedback
  • Asking “what if” questions…
  • “What if we move this capability to another bounded context?”
  • “What if we break up this capability and move one of the sub-capabilities to another bounded context?”
  • “What if we split the bounded context into multiple contexts?”
  • “What if we take a capability from each of these 3 contexts and use it form a new context?”
  • “What if we duplicate functionality to break a dependency?”
  • “What if we create a shared service to reduce duplication across multiple contexts?”
  • “What if we isolate the truly core capabilities and move the others into a separate context?”

If you prefer a visualisation of these transformations you may find the following useful:

Image for post
Image for post
Image for post
Image for post
Image for post
Image for post

5. Closing Presentation

A presentation of between 5 and 10 minutes is usually sufficient.

Things to consider in a presentation:

  • Focus on the core domains: how does each design enable the core parts of the system to be developed more effectively?
  • Compare domain flow stories: how did one system design reduce complexity and number of dependencies.
  • Explain what you will do next to validate your preferred choice

Training and Consulting

If you are seeking help exploring your domain, designing your system, or training your teams, contact me for further information. I work with a network of highly-experienced DDD practitioners who are passionate about designing effective sociotechnical systems aligned with the business goals and domain.

Technology Strategy Ideas and Insights

Domain-Driven Design, Organisation Design, Continuous…

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store