Bounded Context Canvas Recipe: Use Case Swimlanes

Nick Tune
Nick Tune
Oct 3 · 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 default Bounded Context Canvas format reads from left to right, showing messages flowing into the context (inbound communication), with some rules being applied in the middle (business decisions), followed by messages flowing out of the context (outbound communication).

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)

Uncovering Design Insights

When organising into swimlanes a light is shined on the design from a different perspective, accentuating questionable design choices or leading your mind to consider alternative choices.

Searching for Better Boundaries

One of the obvious avenues of exploration is to consider extracting each swimlane from the context. It encourages you to ponder, how much information is actually shared between the decisions in each use case? How many decisions are shared between use cases? What would happen if we took this use case out of the context and move it to another? Or what if we split the context into two smaller groups of use cases?

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

Another insight I get from the swimlane view is over-complicated interactions between a bounded context and it’s collaborators. By viewing all of the interactions in a single place, as swimlanes, the complete picture makes awkwardness in the design stand out.

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?

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

How we visualise information constrains our thinking. But it also gives us a fresh perspective, one we might not have otherwise considered.

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.

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