Microservices and The Bounded Context: Part 1

tl;dr The mapping between a bounded context and a microservice isn’t always one to one, it may be one to many. Which approach should you choose? It depends. Part of the issue here is language, so part 1 covers terminology and part 2 covers examples.

The microservices community has does a lot to increase interest in Domain Driven Design (DDD). In doing so, many concepts that the DDD has long supported, such as the idea that shared databases drastically reduce agility, have become mainstream. As Eric Evans says in his 2018 Explore DDD keynote, this for the better.

But as Eric also says, the deluge of microservices content has made popular the reductionist notion that there should be a one to one mapping between a bounded context and a microservice. This isn’t too surprisingly, given that the learning curve presented by DDD terminology often leads to oversimplification by new users. Nonetheless, deeply understanding the relationship between microservices and the bounded context can be rather useful when working in complex systems. Therefore:

1. Part 1 of this series will attempt to clarify the bounded context concept, as well as its relationship to microservices and DDD more generally.
2. Part 2 will explore examples of the relationship between bounded contexts and microservice in order to provide practical guidance on the way delivery teams can use this relationship to their advantage.

So let’s start with the microservice, for which the second paragraph of the Lewis & Fowler article is more than sufficient:

In short, the microservice architectural style [1] is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.

As for the bounded context, it’s difficult to explain in isolation, so we’ll need to take an short, incomplete, tour of Domain Driven Design [1]. Simply put, DDD is a set of guiding principles that together form an opinionated perspective on how to design software. DDD is differentiated by the terminology used to express its core principles, so I’m using bold and italic to highlight the terms in this section. This terminology is both a powerful foundation for experienced practitioners, and a confusing obstacle for newcomers.

The first term we should define here is domain, which is the business problem to be addressed, inclusive of the socio-technical environment in which a solution must exist. Thus, legacy systems, organization structure, and business process are important elements of the domain. This fundamental embrace of systems thinking is what makes the DDD community so intellectually rich and diverse.

The first principle of DDD we will discuss is that domains should be solved for through the creation of models. These models should be created through the collaboration of domain experts and software experts. Ultimately, the model should be expressed explicitly in working software.

Model is a really important and carefully chosen word. By definition, models are a simplification of a system or process. Thus, realism and completeness are at best a distraction when creating a model for a domain, and at worst, a recipe for disaster. Distilling out the key elements of a domain in order to build an effective model is the central practice in DDD, often facilitated by techniques like Event Storming or Domain Storytelling. You may hear this practice called knowledge crunching.

Because models are a simplification, they work best when they focus on a specific, often difficult, problem. The corollary of a focused model is that it has limits. We use the term bounded context to mean the limits in which a domain model is useful and consistent.

Some teams are able to adequately address their domain with a single model. Thus, all of their work exists in a single bounded context. Other teams may have more than one problem to address, and DDD encourages these teams to build several, small, purpose built models for their domain, instead of a single, large, general model. Herein lies the fundamental connection to microservices — small and focused is preferred to large and general.

Moreover; bounded contexts also express a team boundary. Just like a microservice, a bounded context should only be maintained by a single team, though a single team may choose to maintain more than one bounded context as discussed earlier.

When working with several models to solve for a domain, it’s possible that the same concept is represent in each model, but in different ways. In this case, the bounded context is an important tool for disambiguation. It’s often important to mention which bounded context you are discussing in conversation or at the whiteboard.

This brings us to the final principle we need to discuss. Human language, whether spoken, written, or coded in software, is the best tool for designing and exercising your models. If the language is difficult or cumbersome, that is a clue that the model is not as effective as it could be, and that the team should look for ways to improve the model. Thus, the term domain language refers to the vocabulary needed to define and communicate a particular domain model. Because domain language should be intentionally and carefully used in all mediums (written, spoken and coded), it is also referred to as ubiquitous language.

We have now established 1) a baseline for the term bounded context and it’s use in Domain Driven Design, 2) a baseline for the term microservice, and 3) the fundamental connection between the ideas. The last thing to do before exploring examples is to highlight that the bounded context is at a higher level of abstraction than the microservice. A bounded context simply identifies the borders of a domain model, which in other words, means that a bounded context identifies in which situations it is approach to speak, write or code using our carefully crafted domain language. As we will see in part 2, a team may choose to have several of these domain languages and will need to translate between them. The bounded context helps us manage that complexity by telling us what language we are speaking and if we need to do any translation.

That said; a bounded context does not dictate how that model will be deployed in running software. In fact, the original Domain Driven Design text covers a wide variety of options. On the other hand, microservices do present guidance on how to deploy software and exploring how that guidance is related to bounded contexts will be the focus for part 2 of this series.

[1] This incomplete tour of DDD concepts is derived from Eric Evans 2017 Explore DDD keynote, as well as my own practice. It is focused on the strategic part of DDD, the branch of thought that is concerned with the relationship between teams and software assets, as well as the ways organizations can structure these relationships for maximum business value. The other branch of DDD is called tactical, and is concerned with specific design patterns for implementing software. The tactical part of DDD is relatively well known in software development today (even if not practiced), and some patterns (e.g. the Repository for data access) are common place.