I was wrestling quite a bit with my colleagues recently about how we could benefit from DDD, especially from the notion of bounded contexts. We somehow felt that the concept is an important building block for how we split up our services, but we had some trouble to really make the DDD ideas work in practice.

Right in time, I stumbled across a video by Nick Tune which I found very useful (full video is linked at the end of the post). And despite the fact that his views seem to upset parts of the hardcore DDD community, I found his core idea really interesting: He suggests to link the idea of bounded contexts strongly to the idea of team autonomy, and he concludes that bounded contexts should be primarily reflected in teams that own “product and tech things” that change together for a business reason.

For Nick bounded contexts are merely a tool to create a large number of different models of how things could be split up. And based on these different options he suggest to apply the Theory of Constraints to select (and justify the selection!) of a certain cut. Always questioning whether this specific cut really resolves a bottleneck for quick software delivery. And once a cut is found, it then has to be reflected in the organizational architecture (=the team setup) as well to be effective.

Here’s a few take-aways on the approach in general:

Understand the business you’re in

Sounds pretty obvious, but it’s worth stating: thinking about bounded contexts doesn’t make sense from a purely technical point of view. The starting point has to to be the business model, the business problems one wants to solve, the process steps thins involves as well as the the customers’ needs.

Start with a broad funnel of different models

Starting with the definition of bounded contexts right away is difficult. There are tools though that can be used very beneficially as clues for how the bounded contexts could look like that are worth exploring. These include linguistic boundaries (i.e. same/similar phrases that have different meanings in different parts of the business), data/data flow considerations (who owns which data? how does data flow? are there dependencies between data?), domain expert boundaries (what’s the area that a single expert can cover and where does the expertise of the other person start?), as well as business process steps (which sometimes map directly to bounded contexts).

Another category of clues can be the existing organizational setup. However, I don’t like that too much as a clue, as - especially in a startup setting - the organizational design is often less deliberate and less stable than we would want it to be for this purpose.

Now, once we have enough clues how different cuts of bounded contexts could look like it’s time to compare them and select a winner.

Picking the right cut for your bounded contexts

Now, here’s the key learning: Pick the right cut of your bounded contexts based on the bottlenecks you want to resolve. So to the disappointment of my inner engineering soul it’s not about picking a model that feels elegant, or tidy, or smart by any other engineering measure. It’s about removing constraints/bottlenecks. And these bottlenecks need to be carefully evaluated as they need to serve as the main justification for the cut. And, surprise, surprise, these bottlenecks can often be found in team organization, team communication issues, and team dependencies.

The bottlenecks are a function of what we want to optimize for. I personally like to work in environments that produce innovations, and for those kinds of environments I feel a broad consensus that speed of incremental software delivery that allow for fast feedback cycles on ideas and rapid improvements is the most important optimization goal. And that aligns well with the notion that bounded contexts together with the right team setup can help to solve coordination bottlenecks by cutting dependencies at the right spots.

Can you cut all dependencies?

I have never seen a real world system that looks as nicely cut as any of the book examples. Reality tends to be messy, so the expectation of having all clean boundaries everywhere is something that I would say is just not achievable in a real world system.

So the best outcome one might expect from the exercise is probably a cut of contexts and teams that are reasonably independent to deliver on their core purpose. But how to you then make sure that there is still good alignment between those remaining ugly dependencies and the teams responsible for those? Nick suggests a couple of activities that very much focus on the human side of this alignment, basically saying that everyone should have a good overall understanding of the different corners of a system by e.g. show & tell events, occasional cross-team pairing, or event storming sessions as an artifact that fosters this common understanding.

On top of that, the bounded contexts should be allowed to evolve over time alongside the teams, the changes in business processes and needs and technical discoveries that occur as we go.

Interested to learn more first hand from Nick? Then watch the video: