SIMPLIFIED

Decomposition Visualizer

A problem at the root, subproblems below, the pieces you would build at the leaves. Edit the tree and the page scores its shape live — by capability or by layer, testable leaves or headings, seven children or seventeen.

Problem→Understand→Requirements→Constraints→Unknowns→Decomposition→Smallest Step→Model→Experiment→Observe→Debug→Learn→Iterate

The first decomposition most people draw is Frontend / Backend / Database. It is true of every application and therefore says nothing about this one. A decomposition earns its place when each piece is understandable, testable, meaningful and small enough — and the test for "testable" is a sentence: what would you see that shows this piece works? Load the anti-pattern, watch the score, then fix it one node at a time. Double-click a name to rename it; click a node for its controls.

Presets

By capability, not by layer: seven things a store does, with Checkout expanded into the six steps §20 walks through. Every leaf says how you would know it works.

Decomposition by Capability →

score

100 / 100

nodes · leaves

29 · 21

testable leaves

21 / 21

depth

verdict

Every leaf is testable and the tree is by capability — the structure has nothing obviously wrong with it.

The tree — highlighted nodes carry a warning

- - testable GET /products returns every active product with name and price.
  - testable Opening a product shows its description, price and stock state.
  - testable Searching "lamp" returns only products whose name contains it.
- - testable Adding a product makes it appear in the cart with quantity 1.
  - testable Setting quantity to 0 removes the line; the subtotal follows.
  - testable Reloading the page shows the same cart.
- - testable Checkout starts with exactly the lines the cart holds.
  - testable A line whose product went out of stock is refused with a message naming it.
  - testable Total equals the sum of line prices plus shipping, never negative.
  - testable A payment intent exists for the total before any order does.
  - testable A successful payment yields exactly one order with the cart's lines.
  - testable The customer sees the order number and receives an email with it.
- - testable A customer sees their own orders and nobody else's.
  - testable An order moves placed → paid → shipped, and never backwards.
- - testable A test card is charged the order total once.
  - testable A declined card leaves no order and shows the decline reason.
  - testable A payment confirmed by webhook marks its order paid, even if the browser closed.
- - testable Ordering two of a product with stock 5 leaves stock 3.
  - testable Two orders for the last unit produce one order and one refusal.
- - testable A product created in admin appears in the catalog.
  - testable Setting stock in admin changes what checkout allows.

As an outline — two spaces per level, "Name — testable observation"

Build an online store
  Catalog
    List products — GET /products returns every active product with name and price.
    Product detail — Opening a product shows its description, price and stock state.
    Search by name — Searching "lamp" returns only products whose name contains it.
  Cart
    Add item — Adding a product makes it appear in the cart with quantity 1.
    Change quantity — Setting quantity to 0 removes the line; the subtotal follows.
    Persist cart — Reloading the page shows the same cart.
  Checkout
    Load Cart — Checkout starts with exactly the lines the cart holds.
    Validate Items — A line whose product went out of stock is refused with a message naming it.
    Calculate Total — Total equals the sum of line prices plus shipping, never negative.
    Create Payment — A payment intent exists for the total before any order does.
    Create Order — A successful payment yields exactly one order with the cart's lines.
    Confirmation — The customer sees the order number and receives an email with it.
  Orders
    Order history — A customer sees their own orders and nobody else's.
    Order status — An order moves placed → paid → shipped, and never backwards.
  Payments
    Charge card — A test card is charged the order total once.
    Handle failure — A declined card leaves no order and shows the decline reason.
    Webhook reconciliation — A payment confirmed by webhook marks its order paid, even if the browser closed.
  Inventory
    Decrement on order — Ordering two of a product with stock 5 leaves stock 3.
    Prevent oversell — Two orders for the last unit produce one order and one refusal.
  Admin
    Create product — A product created in admin appears in the catalog.
    Adjust stock — Setting stock in admin changes what checkout allows.

How to read this page honestly

What the tool does, and what it deliberately refuses to do.

SIMPLIFIED

The score reads shape and names, not meaning. A leaf whose testable text is "it works" passes; a capability called "Orders" that should have been "Refunds" scores the same; "Persistence", "Rendering" and "Transport" are layers by another name and dodge the layer rule. A hundred means "nothing obviously wrong with the structure" — a well-shaped tree of nonsense scores a hundred too. And the to-do preset is deliberately boring: a problem that small barely needs a tree, and decomposing it further is decomposition for its own sake.

Take it further

Decomposition by Capability →

Why capabilities cut through layers, and layers cut through nothing.

What Makes a Good Subproblem →

Understandable, testable, meaningful, small enough — the four tests behind the score.

What Should I Build First? →

Turn the leaves into features with dependencies and pick an order.