Boundary Volatility Test
Evaluating a proposed service boundary by asking whether the things on either side change for different reasons and at different rates.
A good boundary separates things that change independently. A bad one cuts through something that always changes together, so every feature crosses it.
The practical test, applied to the last six months of real changes: how many touched both sides? If most did, the boundary is wrong regardless of how clean the diagram looks. This is evidence rather than opinion, and it is available from version history for free.
Supporting signals:
Different reasons to change — a pricing engine and a notification service change for genuinely different business reasons. An order service and an order-validation service usually do not.
Different rates of change, which is what justifies separating a stable core from a volatile edge.
Different teams, because Conway's Law means the boundary will end up where the communication cost is anyway.
Different scaling or availability requirements, which is a legitimate reason to separate things that otherwise belong together.
The counter-signal that outweighs the others: a boundary that requires a synchronous call on every request has created temporal coupling, multiplying availability downward. Either the boundary is wrong, or the interaction must be made asynchronous.