Problem Decomposition

"Build an e-commerce platform" cannot be built; "list products", "add to cart" and "create an order" can. Decomposition is the move from the one to the other — and the split is judged by whether each piece could be built and checked on its own.

Browse a product, add it to a cart, check out: a capability is something an actor can do, end to end, that you could demonstrate. Splitting a problem along capabilities gives every piece a test in the user's words and a natural order of work.

Frontend, backend, database is a true statement about the solution and an empty one about the problem: it fits every application, so it distinguishes none. It is still the right split in a few specific situations — when the product is already known and one layer is the problem.

A useful subproblem is understandable, testable, meaningful and small enough to build without further splitting. Most bad decompositions fail exactly one of the four, and naming which one tells you how to fix it.

Layer-only, too wide, too deep, a single child, vague names: the five shapes a decomposition takes when it has stopped being about the problem. Each is visible in the tree's outline before any code is written.

A child that is still too big is decomposed the same way its parent was. Checkout becomes Load Cart, Validate Items, Calculate Total, Create Payment, Create Order, Confirmation — and the recursion stops where a leaf could be built on Monday and checked on Friday.

Checkout depends on Cart, Inventory, Payment and Orders — but not all in the same way. Some must answer before the customer can be told anything; some can be told later. Drawing the edges, and marking which kind each is, turns a tree into an order of work and a design for what happens when a dependency is slow.

The whole module applied to one capability: checkout from a sentence to testable leaves, with the layer it crosses, the decisions the split surfaces, the dependency it cannot control, and the tool it did not need.