Bounded contexts: why designing them well matters

· Published · 2 min read

I have already explained why it pays to analyse the subdomains of your business domain, then the difference between subdomains and bounded contexts.

Now it is the turn of bounded contexts themselves: what is the point of designing them well?

(Important reminder: bounded contexts are created by design; they do not come out of an analysis of the business the way subdomains do.)

Several things.

1. Protecting your models and their languages

This is the most important one.

In DDD, you try to model with well-chosen, unambiguous business terms, so that the code “speaks” the business. But sometimes the same (good) term means different things depending on the situation. That is the sign you need two (or more) bounded contexts, so that the term has only one meaning per context.

2. Making your life easier

Even when the language is the same, you can have different teams, different deployment needs, different scalability needs: all good reasons to split those parts into several bounded contexts.

That way you reduce the organisational constraints on the code, which stays freer to be the best possible version of itself.

3. Analysing your program better and guiding your technical choices

All thanks to the context map (the map of your bounded contexts and their relationships):

  • Which bounded contexts are upstream? Downstream? (Who depends on whom.)
  • Which ones belong to core subdomains and need to be looked after? (For example with an Anti-Corruption Layer when the core is downstream, or an Open Host Service when it is upstream.)
  • Which ones belong to supporting subdomains, and can strategically settle for following another one’s model? (Conformist)
  • Could some parts be shared in a Shared Kernel, to avoid too much duplication?
  • Or, on the contrary, live their own lives, each in its own corner? (Separate Ways)

A strategic level

We are at a strategic level here. And for us developers, it too often seems “not that important”.

Yet this analysis is absolutely key: to understand what you are doing, spot problems and fix them (or avoid them), and know where to use which pattern and why (rather than “by instinct”). That strategic level is what I bring to the teams I support.

In the end, the code behind it:

  • has a much better chance of being well thought out and designed
  • will have far fewer bugs
  • will be far less disposable
  • will be neither over- nor under-engineered, given its role and value in the project

If all this interests you, go read a book on DDD. I am only paraphrasing and simplifying concepts that go much further than these overviews.

Happy designing!