One of the core concepts of Domain Driven Design (Eric Evans) is the Bounded Context.
Here’s an excellent summary of the Bounded Context in DDD and a specification of how it should relate to source code organisation and team structure.
The summary states that:
- There must be a team assigned to work on a Bounded Context.
- There should be a separate source code repository for each Bounded Context.
- It is possible that one team can work in several Bounded Contexts, but several teams should not work in a single Bounded Context.
This ties in with the notation of what Team Topologies says about team organisation. That a team should work on one context and they should be able to work independently on delivering value to that context – and therefore (if properly organised) the customer.
Making a team responsible for a bounded business context (in another source code repo) without it becoming a bottleneck to progress implies a few things:
- All changes to that service need to be made by this team
- The resulting service is independently released, and, therefore, the service supports multiple versions of interfaces necessary for other services.
Does this mean that the code needs to be separate repos? I would argue not necessarily.
Does this mean that the architecture needs to be microservices? No, not at all. This could be a part of a monolith if the release cycle is independent.
The key to flow is picking the right boundaries to define the context.
In the simple case, it’s relatively straightforward.
In the more complex case, it is more difficult to find a boundary which will result in a context (and service) that can be independent. This approach to finding Independent Services through Heuristics method is interesting and shows the power of tackling this service design visually.
It also highlights how architecture, code and team alignment is intrinsically linked with service design.