For a while now, we have been using Domain Driven Design (DDD) at TicketSwap to help us guide the design of our software systems. This is a messy journey, and certainly not one that is over yet… not by a longshot. Throughout our journey we’ve revisited various believes we’ve held about our domain and business rules multiple times, and we are continuing to discover new and different things every time we do so. This is especially interesting when new people join our sessions that come with interesting questions and insights. Very recently we’ve had a new business development that again questioned our mental models, and specifically how this new business idea would fit in there. So, we thought it was time to revisit past believes and rediscover. This recounting of our journey is not one for a single post, so this is the second in the series. Read the first and second post if you haven’t already.
Connecting
With a map of subdomains in hand, we were still only at the stage where we had gotten more insights into the overall picture, but it was a thousand mile overview, and the bounded contexts didn’t have any connection to each other yet. The first step we took was putting up all the bounded contexts as separate stickies on a big wall. We then tried to draw relationships where we saw them, ie. do some context mapping.)If you remember from the last post, we decided to consider the SecureSwap™️ and new business development (I can now actually mention the name: Sealed Tickets™) as two separate things, and thus put them up the wall as such. A context map tries to describe the contact between bounded contexts and teams with a collection of pattens. There are multiple connections patterns that each describe a different perspective, which enables a more holistic overview of the relationships. We ended up with something incredibly incomplete, but useful and usable.
Having this map of how the bounded contexts connected to each other gave us a better overview of the landscape. Which helped to put things in perspective in the next step.
Diving deeper into bounded contexts
We did all of these exercises to answer the original question: how does the new business development fit into the rest of the system? In order to get a real deep sense of what we’re talking about, we dove deeper into the related contexts using a bounded context canvas.
The canvas guides you through the process of designing a bounded context by requiring you to consider and make choices about the key elements of its design, from naming to responsibilities, to its public interface and dependencies.
By not just looking at a bounded context from a higher abstract level, but really diving into it, and being specific on it’s in- and outbound communication, language, business decisions, etc, the discussions don’t stay vague but are directly tied to what happens (or should happen) in a system. Constantly looking at the previous models, like the context map, made sure we did not suddenly forget something in a next session (and checked if we maybe had it all wrong previously).
We decided on focussing mostly on the bounded contexts that were closest related to the problem at hand, since filling these canvasses already takes some time, and that is where we would get most of the value.
At the time, the bounded context canvas did not have much documentation beyond what was written on the canvas template. Thanks to Maxime Sanglan-Charlier we now have some good usage examples documented which should help future teams in future sessions a lot.
Shocking conclusion
When we started out we initially operated under the notion that SecureSwap™ and Sealed Tickets™ were two closely related, but still different things and should therefor be considered differently in both the problem and solution space. However, as we progressed through connecting the contexts and dove even deeper into the details, we figured that there was so much overlap between the two contexts in the problem space that it didn’t feel like different things anymore in the solution space either.
Thanks to Nick Tune and his insightful post about Mapper Contexts & Supercontexts we came to the insight that since these were not the same thing, but not completely separated either, an encompassing super context could be thought of that fit very well!
The end (for now)
This is the mental model we settled on for now. There are still open questions (the red stickies), but the answers to these questions will evolve from here. With this mental model in our minds, it “clicked”. We knew better where the boundaries would lie of Sealed Tickets™, and we knew better how to make sure we weren’t doing the same work twice (ie. The ticket provider integration).
And with that, this journey came to an end, at least for now.
