I Know What I Need, But I Don't Know How To Build It
Pick the thing you need. Then derive it: meaning, state, operations, rules, examples, representation, pseudocode — and only then the code, one rung at a time.
“I know I need a shopping cart. I have no idea how to implement a shopping cart.” The gap is not a missing tutorial; it is a missing method. Every stage below asks you to write before it shows you anything, because the code is the last step of a derivation, not the first thing to search for.
Which concept?
Grouped by exercise level; the level is how far the derivation goes, not how hard the code is.
How much help?
Every stage's content is shown right after your attempt box.
Payment Workflow — twelve stages
I know I need to take a payment for an order. I have no idea how to implement a payment workflow.
Define the concept
In one sentence, without any code: what is it? Then answer for yourself — does it have identity, who owns it, how long does it exist, should it survive a reload or a login?
Payment Workflow = The record of one attempt to collect money for an order, moving through a fixed set of states as the system, the customer and the payment provider act on it.
- Does a payment have identity? Yes, strongly. Two payments for the same order and amount are different attempts — one may have failed and the other succeeded — so each gets an id the moment it is created, and the provider is told that id.
- Who owns it? The order it pays for, and through the order, the customer. But the truth about whether money moved belongs to the provider; the workflow owns the state, not the money.
- How long does it exist? Forever, in practice. A payment is a financial record; it is never deleted, only moved to a terminal state (failed, refunded) and kept for audits and disputes.
- Should it survive reload? It must. A payment that exists only in memory can be confirmed by the provider after the process restarts, and then the confirmation has nothing to attach to. Persistence is not a later option here; V0 only defers it to learn the states first.
- Should it survive login? It is not tied to a session at all. The provider confirms it by id, hours later if it likes, with no user present. That is why the confirmation cannot require the customer to be logged in.
The catalog is one derivation, not the only one (impl §60). A different set of examples yields different rules; a different first requirement yields a different V1; a map instead of an array is not wrong, only an answer to a different question. Compare your derivation with the reference for the differences, then decide which ones were rules and which were style.
Take it further
The flagship exercise: the cart typed by you, with the reference hidden until you ask.
Make It Smaller Until You Know How to Build It →The principle behind the ladder, and the primitive chain it produces.
The Implementation Loop →The loop the twelve stages follow, and why the code is last.