“One micro-service should cover one bounded context” asserts Vaughn Vernon.
It leads to an interesting tweeter discussion with Greg Young, Romeu Moura and Mathias Verraes. Greg and Romeu disagree. I say it depends of the context.
To know if one can cover another, we must know what a micro-service is and what a bounded context is. I find their definitions are fuzzy, and I think this discussion is a proof of that. I’ll try to clarify my point in this article.
Disclaimer: the following definitions are based on my current understanding of DDD strategic patterns, I don’t claim they are the only true definitions.
Micro-service definition
We believe we know what is a micro-service until we take a look at the Wikipedia definition.
“In contrast to SOA, micro-services gives an answer to the question of how big a service should be and how they should communicate with each other. In micro-services architecture, services should be small and the protocols should be lightweight.”
This definition is symptomatic of our industry: we explain something by something else we don’t understand either. Do we share a common understanding of what is “small” and “lightweight”? I don’t think so.
A better explanation is the second property in the details of the Wikipedia page: “Services are organized around capabilities, e.g., user interface front-end, recommendation, logistics, billing, etc.”
To be fair, this property has lots of symmetries with how we define a bounded context.
Domain definition and problem space
To understand what a bounded context is, we need to define what a domain is. It is a theoretical representation of a business, in the problem space. And it can be divided in sub-domains.
For example in the well-known business of Amazon, the core domain is about selling stuff online, and there are different sub-domain more or less generic like shipping, billing, advertising and so on.
We are in the problem space because we have no idea (yet) about how we should implement Amazon’s business, it is just a theoretical description of what they do.
DDD patterns that are applicable to the problem space (figure 1-4 page 10 of PPP of DDD)
Bounded context definition and solution space
A bounded context is a projection in the solution space to define boundaries in the system implementing the domain. Bounded contexts are important because they allow to define an ubiquitous language, valid within their boundaries. A product in a billing bounded context has not the same meaning than in a shipping bounded context.
When it is badly done, we obtain a big ball of mud, e.g. a huge system without boundaries where an update in the billing part may cause side effect in the shipping part.
We are in the solution space because it is an actual description of how we implement the domain. A bounded context does not necessarily matches exactly one sub domain. But having too many bounded contexts overlapping between different sub-domains is definitely a design smell.
DDD patterns that are applicable to the solution space (figure 1-5 page 10 of PPP of DDD)
One micro-service should cover one bounded context?
Now that we defined micro-service and bounded context, we can try to decide if one micro-service should cover one bounded context?
And of course, we still cannot decide, because we still lack the (business) context. In some business context, a micro service might fit a bounded context. In some other, several micro services will be in one bounded context. The only thing we can suppose is that a micro service overlapping different bounded contexts has something wrong.
As usual in any DDD discussion, context is king.
For more thougths on bounded contexts and micro-services, there is this excellent podcast by Eric Evans.