Bounded Context Canvas Recipe: Use Case Swimlanes

Nick Tune
Nick Tune
Oct 3, 2020 · 5 min read
Image for post
Image for post

Don’t let the tools you use overly-constrain your thinking. Use them as a starting point for design and discovery, and then bend them to your needs.

Alberto Brandolini says that EventStorming is his pizza and you can add your own topping. Every tool you use is somebody’s pizza, and you should always look for opportunities to tweak the recipe and find something that tingles your modelling tastebuds.

If you’re not familiar with the Bounded Context Canvas it is a tool for visualising the key design choices of a Bounded Context or a sub-system in your software architecture. It looks like this:

Image for post
Image for post
An empty Bounded Context Canvas

Rather than taking this image as the one true way or a best practice. Treat it as a starting point, or as a sensible default. If you’ve not used it before, or you’re not sure where to begin, start here.

I’ve been using the canvas for a while. I use the default a lot, but I also bend it to my needs a lot. One of the recipes I like to use is modelling each feature or use-case as a swimlane.

Use Case Swimlanes

The connection between the messages flowing in, the decisions in the middle, and the messages flowing out, however, is implicit. It’s not always easy to see which rules apply to which messages, or which inputs trigger which outputs.

Working with different clients, in completely different domains, this limitation arises frequently. And the solution is simple: reorganise the canvas into swimlanes:

Image for post
Image for post
A Bounded Context Canvas organised into swimlanes (1 per use case)

V4 of the Canvas is flexible and can be extended vertically, so you can stretch the canvas to show as much information as you need to.

Uncovering Design Insights

Searching for Better Boundaries

Image for post
Image for post
Each swimlane represents a separate responsibility that could potentially be moved out of the context

In the previous canvas, it’s reasonable to consider whether booking availability should be coupled to making and cancelling bookings. Even the responsibilities of making and cancelling bookings could be considered as belonging to separate bounded contexts.

Challenging Chatty Interactions

In the example below, the Onboarding context has a chatty interaction with the Profile context. It sends multiple commands each as a separate interaction after the previous one is completed: Create Profile, Add Address, Set Membership type (basically a bunch of CRUD events).

Image for post
Image for post
This interaction looks a little chatty. Does Onboarding need to know so much about Profile?

Whenever we see an interaction pattern like this we get another free design option: Remove Chatty Interaction. In this case, it looks like Profile is just an anemic information store and Onboarding contains all of the rules. Should Onboarding really know the process for the individual steps for setting up a profile?

In a situation like this, chances are that Onboarding has a similar relationship to other contexts. Onboarding has become a Brain Context which accumulates all of the rules, becoming overcomplex and coupled to everything.

What happens if we explore the free design option? The free design operation (removing the chattiness) is to combine the consolidate the chatty interaction into a single interaction. One command, Setup Profile, that takes all of the information and sets up the profile in the correct order (we again bend the canvas by showing the information on the message which isn’t the default).

Image for post
Image for post
The chattiness has gone and encapsulation is greatly improved

Now the chattiness is gone, Onboarding is simpler. It is less coupled to the inner workings of Profile. Profile can now be fully responsible for ensuring each user’s profile is in a valid state. And if the process of setting up a profile changes, it’s much more likely that only Profile will need to change.

Free Design Feedback

By organising the Bounded Context Canvas into use case swimlanes we get free design options. Every swimlane comes with free questions like “do these messages and decisions really need to belong in this context?”

The more we experiment with visualising the design of a bounded context, the more alternatives we consider, and the more likely we are to converge on a better design.

I hope you find the default-format Bounded Context Canvas to be a great starting point for your design journey. But I hope it’s not the destination, too.

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