Service Boundary Heuristics
The signals that indicate where a service boundary belongs, and the ones that reliably mislead.
Boundaries drawn badly produce distributed monoliths — services that must be deployed together, chained across the network to serve one request, and share a database — which combine the costs of both styles with the benefits of neither.
The signals that indicate a good boundary. Business capability: the service does something the business would name. Data ownership: it owns its data exclusively, and no other service reads its tables. Rate of change: things that change together belong together, which is the single most predictive heuristic in practice. Team ownership: one team can own it entirely. Autonomy: it can serve most requests without synchronous calls to others.
The signals that mislead. Technical layering — splitting into a data service, a business logic service and an API service produces maximum coupling, since every feature touches all three. Nouns from the database schema, which produce anaemic CRUD services with the actual logic scattered among callers. Organisational structure as it is today, which changes at the next reorganisation while the boundary persists. And size, since "small" is not a design criterion and the pursuit of small services is how estates end up with four hundred of them.
The test that exposes a bad boundary quickly: how many services must change to deliver a typical feature? If the answer is routinely more than one, the boundary is in the wrong place, and the network between them is pure cost.