Bounded Context Canvas Recipe: Use Case Swimlanes

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:

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:

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

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?

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).

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).

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.




Domain-Driven Design, Organization Design, Continuous Delivery

Recommended from Medium

Elastic Beanstalk made simple: End-to-End automation with CloudFormation

Beginner’s Guide to Load Testing with k6

The Eudora™ Email Client Source Code

FOSS Fund Gives Sponsorship Decision to Open Source Contributors

A practical guide for software engineers

5 Habits of Highly Successful Modern Software Teams

Installing OpenSSL on Windows 10 and updating PATH

The Case for Consistency over Perfection

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
Nick Tune

Nick Tune

Technical Leader | Socio-Technical Architect | Continuous Delivery

More from Medium

Architecture & DDD Kata: Online Car Dealership

DDD Beyond the Basics: Mastering Multi-Bounded Context Integration

Domain Driven Design— Solving the problems for solutions

Clear separation between internal and external domains the Propeller way

Implementing LaunchDarkly with no clear separation between domains