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

The basic recipe is composed of the following activities:

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

You need a lot of space for this workshop. If all you can get is a cramped up boardroom, you’re going to be disappointed with the results. Each group of four people will need at-least four metres of wall space

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

If you want to design systems, you need two things: a big enough overview of the whole system and deep enough details of each area. For this purpose, we start with 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

With your domain modelled wide and deep as an EventStorm, you can then begin to group and organise the pieces into bounded contexts.

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:

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

You may immediately identify multiple possible ways to model the system. For now, choose one to work with and make a note of the other possible models (they will be useful later). You may also realise that you are lacking domain information. If so, consider doing another round of EventStorming.

3. Domain Message Flow Modelling

One way to test the validity of your design and gain feedback on how to improve the design is to visualise how bounded contexts must collaborate to solve full business use cases for users of the system.

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

As your domain flows identify relationships between bounded contexts you may immediately uncover obvious design flaws or missing capabilities. You are free to return to the previous activity and update your candidate contexts or perform a second iteration of EventStorming.

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

The next step of the design process is to design your candidate bounded contexts by detailing key design criteria.

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

Begin by filling in the name of your bounded context and a description. The description should describe the purpose the context plays in the domain and it’s role in the business, not implementation details.

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

Treat it as design feedback when you cannot think of a clear name or write a cohesive, precise description, or your UL terms are ambiguous. Consider redesigning the boundaries now, or make a note and return later (usually better to return later).

4.2 Business Rule Distillation & Ubiquitous Language Capture

Now refer back to the EventStorm and look at the sticky notes you recorded for this bounded context. Look for the most important business rules or policies — try to select the top 3 and add them to the canvas.

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

Accentuating the capabilities provided by the bounded context is the next priority. Not only does this clarify what a bounded context does, it also provides a wealth of design feedback. You can start asking questions like:

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

If you’re struggling to identify many capabilities or you feel some are missing I recommend you return to your EventStorm and model this bounded context in more detail with a specific outside-in focus looking for capabilities required by other contexts/services.

Capability Layering [Optional]

Decompose each capability on your canvas into sub-capabilities. This additional granularity gives you more pieces to play with increasing your ability to find alternative models.

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

Dependencies are essential if we want modularity, but dependencies cause a wide range of business, technical, and social problems. It’s, therefore, essential to discern dependencies, understand their impact, and consider alternative choices.

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:

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

Now that you have completed the, canvas spend a few minutes in your team critiquing the design of your bounded context. Organise your feedback into the following categories:

4.6 Reflect and Iterate

Good design is iterative. Before moving onto the next bounded context, step back and look at the big picture view. Have you learned anything that challenges your design? If you have, re-shape your proposed boundaries now and then continue designing the next bounded context.

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

After creating a canvas for each bounded context and collecting lists of design feedback, the next part of the workshop is a return to exploration. This time, you have a highly-refined body of knowledge to help you explore better design options.

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.

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

To close out the workshop each group should present a selection of the context maps they created and discuss the trade-offs of each design. They should explain their preferred choice and why.

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

Things to consider in a presentation:

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.

Nick Tune’s Strategic Technology Blog

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