The physical distance between the source code of coupled components affects the cognitive effort required to change them simultaneously. It is significantly easier to co-evolve two components implemented within the same file compared to two objects belonging to different microservices—or even separate systems. Therefore, distance directly influences the cost of change.
Lifecycle Coupling
Opposing the cost of change is the concept of lifecycle coupling. The closer the components are, the stronger their lifecycle interdependency: they will need to be tested and deployed together.
Notably, many “monolith to microservices” refactorings started with the goal of reducing lifecycle dependencies—this was what was meant by “decoupling.”
Socio-Technical Distance
Distance is a socio-technical dimension: it is influenced not only by the components’ level of abstraction but also by the organizational structure. Consider these two scenarios:
- Two microservices are implemented by the same team.
- Two microservices are implemented by different teams.
If these microservices need to change simultaneously, the coordination and collaboration efforts will be significantly higher when multiple teams are involved. Conversely, lifecycle dependencies are reduced when the components belong to different teams.
Runtime Coupling
Beyond source code locations, abstraction levels, and organizational structure, runtime dependencies between coupled components also affect their distance. For example, asynchronous integration further reduces lifecycle coupling between components.