Bounded context (DDD) is a good thing to start defining a service boundary with. But practically, it's just too coarse-grained to gain real benefits of microservices.
A service per bounded context means having multiple monoliths. That could be perfectly fine as there's no problem with a monolith. However, with microservices, we want to go further. A bounded context can contain multiple services.
So, what are the right boundaries for services?
I believe it's business capabilities. The fine-grained a business capability can be while still remaining autonomous the small can a service be.
A team per service or a team taking care of multiple services within one bounded context is a good practice. However, a single team should not be working across multiple bounded contexts.
Services should be orthogonal, that is, one service won't affect another.
How do you align your (micro)services?
Top comments (1)
Cover photo by Mark Fletcher-Brown