Decomposition by Capability
Breaking a monolithic system into parts along business capability lines rather than technical layers, so that each part changes for one reason.
The decomposition criterion determines whether the result is an improvement or a distributed version of the same problem.
By technical layer — a data service, a validation service, an orchestration service — guarantees that every business change crosses several boundaries, and produces maximum coupling with the appearance of modularity. It is the most common mistake and it is intuitive, which is why it keeps happening.
By business capability — order management, pricing, fulfilment, customer credit — produces parts that change for one reason, owned by one team.
The techniques that locate the boundaries: language divergence, where the same word means different things in different parts of the system, which is the cheapest and most reliable signal; change coupling from version history, showing which files actually change together; and data ownership, since a capability that cannot own its data has not been separated.
The sequence that keeps it reversible: modular monolith first, with boundaries enforced in CI, then extraction only where there is a specific reason — independent scaling, independent deployment cadence, team ownership, technology divergence, risk isolation. Boundaries are cheap to move inside one deployable and expensive to move once distributed, and "it should be a service" is not a reason.