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