A team proposes extracting a service. What single test best predicts whether the boundary is right?

Why change history is the best predictor

A service boundary is only valuable if it allows independent change. If a component has consistently changed alongside its neighbours, extracting it produces a distributed component that still requires coordinated deployment — the distributed monolith, which has the operational cost of distribution and the change cost of a monolith.

Change history is evidence rather than prediction. Every other criterion is a judgement about the future that may be wrong; co-change is a measurement of the past that is usually a good guide.

Why the other criteria are weaker

A clean interface in the current design shows the code is well-factored, which is necessary and not sufficient. A well-factored module that changes with its neighbours is a good module and a bad service.

Independent scaling is a genuine reason to extract — and only for the component that actually needs it. It justifies extracting one component, not decomposing everything, and it is frequently cited for components whose load is unremarkable.

Team ownership matters organisationally and is a consequence rather than a cause. Assigning a team to a badly-drawn boundary produces a team that cannot work independently, and Conway's Law then preserves the bad boundary.

The supporting criteria that should accompany it

• Its data is genuinely its own, so extraction does not split a transaction.
• A different operational profile — much higher volume, longer-running work, stricter latency, or a different availability requirement.
• A stable interface, so the contract does not churn.
• An owner, so the boundary is maintained by the organisation as well as by the code.

The practical sequence

Establish it as a module with enforced dependency rules first, and let the change history accumulate. Six months of independent change is strong evidence; a design diagram is not.

Teams that skip this step choose boundaries from a whiteboard and discover them from incidents — and a wrong service boundary is far more expensive to correct than a wrong module boundary.