Define the Concept
A cart is "a temporary collection of products the user intends to purchase, held between browsing and checkout." One sentence, no code — and every word in it is a decision: temporary, collection, products, intends, between browsing and checkout. The state, operations and rules are read off that sentence.
The situation, the reflex, and why it stalls
Every lesson starts where being stuck starts: someone has a problem, and the first move that comes to mind feels like progress.
You know you need a cart. Before any state, operation or class — what is a cart, and how do you know when the sentence is good enough to build from?
The ticket says "add a shopping cart". You know exactly what a cart is — you have used a hundred — and you cannot write the first line, because "a cart" is not a thing you can type. You open a file, write class Cart {, and stop.
Ask an assistant for a shopping-cart implementation, or open a tutorial, and read the class it produces. It has items, addItem, total, maybe applyCoupon. It looks like the cart you meant.
The class arrives with its decisions already made — a stored total, a price on every item, a coupon field — and none of them were yours. You cannot say which of its fields your cart needs, because you never said what your cart is.
- The class arrives with its decisions already made — a stored
total, apriceon every item, acouponfield — and none of them were yours. You cannot say which of its fields your cart needs, because you never said what your cart is. - When the product owner asks "does the cart survive login?", the code has an answer (whatever the tutorial did) and you do not. The implementation was borrowed; the meaning was never established, so there is nothing to check the code against.
- The first bug report — a laptop appearing twice — cannot be classified. Is that wrong? The class does not say; it just does it. Without a sentence about what a cart is, "wrong" has no definition.
The move
Precisely enough to apply it to a problem you have never seen — not a slogan.
- Write the concept as one sentence about meaning, with no code words in it: what it is, what it is for, and where it sits in the flow. The record's sentence is "a temporary collection of products the user intends to purchase, held between browsing and checkout." No class, no field, no verb yet.
- Read the sentence back word by word and treat each word as a decision someone can challenge. "Temporary" says the cart has an end — it becomes an order or is abandoned. "Collection" says there are several, and hints at the shape. "Products" says it points at the catalog rather than copying it. "Intends" says nothing is bought yet — no payment, no stock movement. "Between browsing and checkout" places it in the system.
- Test the sentence with the questions that follow it: does the thing have identity, who owns it, how long does it exist (Does It Have Identity?, Who Owns It, and How Long Does It Exist?)? If the sentence lets you answer, it is load-bearing; if every answer is "it depends on the code", the sentence is decoration.
- Then, and only then, derive. Each word becomes a question for the next step: "collection of products" → what must it remember (What Must It Remember?)? "intends to purchase" → what can happen to it (What Can Happen to It?)? "temporary" → when does it end? The sentence is the root of the whole loop (The Implementation Loop).
The same need, asked three ways
The vague form is where everyone starts, and it is answerable only by code someone else wrote. The best form asks for a sentence and for its consequences at once — it cannot be satisfied by a class, because a class does not say what "temporary" means.
why The best form produces the sentence and the next three questions together; the vague form produces an implementation whose decisions you never made and cannot check.
What the sentence decides
The record's sentence, taken apart. Each leaf is a claim someone could check against a concrete moment — which is what makes it a definition rather than a slogan. The tree is not the cart's decomposition into parts; it is the sentence's decomposition into decisions.
- └temporary— The cart has an end.testable At checkout the cart becomes an order and is gone; an abandoned cart is eventually not there either.
- └collection— Several entries, not one.testable Adding a second product yields two entries; adding the same product again yields one entry with a higher quantity — the count is what "collection" turned out to need.
- └of products— Points at the catalog; does not copy it.testable Renaming a product in the catalog changes what the cart displays without touching the cart.
- └the user intends to purchase— Nothing is bought yet.testable Adding to the cart moves no stock and takes no payment; checkout does.
- └between browsing and checkout— Its place in the system.testable A cart is reachable from any product page and hands its contents to checkout unchanged.
Meaning first, against class first
Both start from the same ticket. One begins by naming the thing and reading decisions off the name; the other begins by typing the class a tutorial would produce. The difference is not the number of lines — it is whether any line can be defended.
class Cart {
items: Item[] // what is an Item? copied from a tutorial
total: number // stored — nobody asked whether it should be
coupon?: string // the tutorial had one
addItem(p, q) {...} // appends; duplicates are whatever happens
}A cart is a temporary collection of products the user intends to purchase, held between browsing and checkout. temporary → it ends at checkout or abandonment collection → several entries; what does one entry hold? of products → a reference to the catalog, not a copy intends → no payment, no stock movement yet between … → reachable while browsing, handed to checkout
The class has answered five questions by accident — stored total, coupon, copied product data, duplicate handling, lifetime — and none of the answers can be traced to a reason. The sentence has answered none of them yet and produced the exact list of questions whose answers will become the state and operations.
The implementation ladder
Concept, examples, pseudocode, code, tests, production — for the concept this lesson is about. Code is the fourth tab, not the first.
Shopping Cart = A temporary collection of products the user intends to purchase, held between browsing and checkout.
- Does a cart have identity? Yes, weakly. Two carts with the same items are still two carts, because each belongs to someone and will become a different order. It needs an id once it leaves memory; in memory the variable is the identity.
- Who owns it? A shopper — a logged-in user or an anonymous session. The owner is part of the state because "my cart" has to be findable again.
- How long does it exist? From the first add until checkout or abandonment. Whether it survives a reload, a closed browser or a login is not a property of the concept; it is a persistence decision made later, and each answer changes where the cart lives.
- Should it survive reload? Usually yes for a store, usually no for a demo. V1 in memory says no; V2 browser storage says yes on one device; V3 server storage says yes everywhere the user is logged in.
- Should it survive login? Only if an anonymous cart and a logged-in cart are merged — a rule that does not exist in V1 and appears as a modification later.
- itemscollection of CartItemkeepThe cart is its items; without them nothing else means anything.
- items[].productIdidkeepThe reference to what is being bought. The catalog owns the product; the cart only points at it.
- items[].quantityinteger > 0keepTwo laptops is one entry with quantity 2, not two entries — the rule "one entry per product" needs a quantity to hold.
- owneruser id or session iddependsSo the cart can be found again by the person it belongs to.
- items[].productNamestringderiveIt would be convenient to render the cart without a catalog lookup.
- items[].pricemoneydependsThe total needs a price per item.
- totalmoneydropEvery screen shows the total.
- currencycodedependsPrices need a currency to be added.
- createdAttimestampdropAbandoned carts might be expired or emailed about.
- update Add item — the updated cart
- delete Remove item — the updated cart
- update Change quantity — the updated cart
- read View items — the list of entries — product id and quantity — for rendering
- domain Calculate total — the sum of price × quantity over the entries
- delete Clear cart — the empty cart
- • Every quantity is greater than zero.
- • One logical entry per product.
- • The total is never negative.
- • An unknown product cannot be added.
- • Quantity cannot exceed available stock — if inventory is enforced here.
How to do it
Most important first.
- Write the sentence in the vocabulary of the person who uses the thing — a shopper says "products" and "cart", never "line items" and "session state" — and keep that vocabulary all the way to the code (Meaning Before Representation).
- Underline every noun and every qualifier. Each is either a decision you are making or a decision you are hiding; say which.
- Say what the concept is not. A cart is not an order (nothing is paid), not a wishlist (it is meant to be bought now), not inventory (it does not reserve stock in V0). Neighbouring concepts sharpen the edge.
- Check the sentence against three concrete moments — first add, checkout, closing the browser — and see whether the sentence predicts what happens. Where it does not, the sentence is incomplete or the moment belongs to a later version.
- Do not let the sentence grow. "A temporary collection of products with quantities, prices, a coupon, a shipping estimate…" is a class disguised as a definition (Challenging Unnecessary State).
Worked on a concrete problem
The move has to produce something. This is what it produced.
- Cart. Sentence: "a temporary collection of products the user intends to purchase, held between browsing and checkout." Three moments: first add — a product enters the collection; checkout — the collection becomes an order and the cart ends, matching "temporary"; closing the browser — the sentence is silent, which is correct: survival is a persistence decision, not part of the meaning.
- Search products by name. Sentence: "a way to find, from the catalog, the products whose names match what the shopper typed." Every word is a decision: "from the catalog" (not from orders), "names" (not descriptions — yet), "match" (exact? prefix? contains? — the first unknown the sentence produces). The sentence does not decide the algorithm; it tells you which question the algorithm must answer.
- Login. Sentence: "a way for a person to prove they are the owner of an account, so that the system can act as that account." "Prove" makes the password one mechanism among several; "act as" says the output is an identity the rest of the system trusts, not a boolean. Two words, two architectural facts, no code.
How you know it worked
What now exists that did not before, and what question you can now ask.
- There is one sentence, in the shopper's words, and you can point at each word and say what it decides.
- The questions that come next — identity, owner, lifetime, state, operations — can be answered from the sentence, or the sentence tells you that they are decisions for later.
- Given someone else's cart class, you can say which of its fields your sentence justifies and which it does not.
The questions you can now ask
The field this whole domain exists for. After this lesson, these are the questions to put to an unfamiliar problem.
- ?What is this thing, in one sentence a user of it would recognise — and which words in that sentence are decisions?
- ?What is it not — which neighbouring concept does it get confused with?
- ?Does the sentence predict what happens at the three moments that matter most, or is it silent — and is the silence correct?
- ?What information does the sentence say the thing must remember?
What can go wrong
- The sentence is written in implementation words — "a cart is an array of item objects with a total" — and it decides the representation before the meaning. That is a data structure with a name, and it cannot be challenged because it has already answered.
- The sentence is so general it decides nothing: "a cart holds things the user wants." True, and it does not distinguish a cart from a wishlist, so the first design question has no answer.
- The sentence is treated as final. It is the first thing written and the most likely to be wrong; when the examples show a second add producing quantity 2, "collection" quietly becomes "collection with counts", and that is the sentence improving, not failing.
- A sentence written before any code can be wrong in ways only code reveals, and a learner who polishes the sentence for an hour has spent an hour not finding out.
- Meaning-first is slow on a concept you have built many times; an experienced engineer carries the sentence in their head and starts from state.
- A sentence in the shopper's vocabulary is sometimes at odds with the vocabulary of the team or the framework, and someone has to translate at every boundary.
- "Define the concept means write the domain model." The domain model — fields, types, relationships — is three steps later. The concept is a sentence; the model is derived from it and can be wrong while the sentence is right.
- "Just start coding and the concept will emerge." The slogan is precise only when the concept is one you already understand: then coding is a fast way to write it down. When you do not know what a cart is, coding produces a class whose fields nobody can defend, and the concept never emerges — it is inherited from whatever you copied.
- "One sentence is too little to build from." It is too little to build the whole cart from; it is exactly enough to ask the next question from, and the next question produces the state. Nothing in the loop is built from the sentence directly.
Where this applies
Problem-solving advice is stated as universal far more often than it is. These labels say what each method is specific to — and where CONTESTED appears, the note gives the strongest form of the opposing view.
- GENERALEvery concept — cart, search, login, rate limiter, job queue — has a one-sentence meaning that the state and operations are read off, and the word-by-word challenge is the same move for each.
- TEAM-SPECIFICA learner needs the sentence written down and challenged aloud; a team that has built carts before carries it implicitly, and the move becomes a review question — "what is this thing?" — asked when a class arrives with a field nobody can explain.
- ILLUSTRATIVEThe cart sentence, the laptop that appears twice and the three moments are the concept record's invented example; no real store or its vocabulary is described.
Where the depth lives
This domain asks the question and hands the answer off by name.