ConceptGENERALCONTESTEDILLUSTRATIVE

Nouns to Data, Verbs to Behaviour

"A customer adds products to a cart." Nouns: Customer, Product, Cart — candidates for data. Verb: add — a candidate for behaviour. It is a heuristic for finding candidates, not a law for finding classes: "total" is a noun and turns out to be a computation, and "quantity" is nowhere in the sentence and turns out to be state.

The moveWorked exampleNext questions

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.

The question

You have the sentence. How do you get from its words to a first list of data and behaviour — and where does the noun/verb trick mislead you?

The situation

You wrote "a customer adds products to a cart and checks out" and now you are staring at it. Something in the sentence is supposed to become code. You have heard that nouns become classes and verbs become methods, and you start typing class Customer.

The reflex

Apply the rule mechanically: every noun a class, every verb a method on the nearest noun. Customer.add(product, cart), Cart.checkout(), Product with whatever fields a product has.

Why it stalls

Three classes exist and the cart still cannot hold two laptops, because "quantity" is not in the sentence. The heuristic found the nouns that were said and missed the state that was needed; the examples would have found it in one line (State Shape From Examples).

What the reflex produces — and fails to produce
  • Three classes exist and the cart still cannot hold two laptops, because "quantity" is not in the sentence. The heuristic found the nouns that were said and missed the state that was needed; the examples would have found it in one line (State Shape From Examples).
  • Customer.add puts the behaviour on the wrong noun. The customer is the *actor*; the cart is the thing whose state changes. Every operation ends up on Customer, and Cart is a bag of public fields nobody guards — the anemic model, produced by grammar.
  • "Total" is a noun, so it became a field, and now it has to be kept in sync on every add and remove. The sentence did not say total was stored; the heuristic did, and the record's state canvas drops it for exactly that reason.
ProblemUnderstandRequirementsConstraintsUnknownsDecompositionSmallest StepModelExperimentObserveDebugLearnIterate

The move

Precisely enough to apply it to a problem you have never seen — not a slogan.

  • Use the sentence to produce *candidates*, and label them as candidates. Underline the nouns — Customer, Product, Cart — and write them as "things that might need to be remembered or referenced". Underline the verbs — adds, checks out — and write them as "things that might happen". Nothing is a class yet.
  • For each noun, ask which side of the boundary it is on. The cart is inside the system and changes: data. The product is inside the system but owned by another concept — the catalog — so the cart holds a *reference*, not the product. The customer is the actor who triggers the behaviour, not state the cart holds — only their id, and only from V1. Three nouns, three different fates.
  • For each verb, ask what state it reads and what it changes (Inputs, Outputs and Side Effects). "Adds" reads the items and the catalog and changes the items — so it belongs where the changed state lives, on the cart, as addItem. "Checks out" changes an order and inventory and consumes the cart; it belongs to checkout and merely reads the cart. The verb goes with the state it mutates, not with its grammatical subject.
  • Then go looking for what the sentence did not say. Write two examples — add Laptop; add Laptop again — and the missing noun appears: quantity. Write "what does every screen show?" and a noun appears that is *not* state: total, a computation over items and prices. The heuristic starts the list; the examples and the state canvas finish it (What Must It Remember?).

From sentence to candidates

The pipeline is short and each stop has a way of failing. The last stop is the one that turns the heuristic into a method: without it, the columns are trusted as if they were the state canvas.

Sentence → data and behaviour
  1. 1
    Sentence

    "A customer adds products to a cart." One sentence, in the shopper's words.

    fails by A paragraph, or a sentence in implementation words ("the session stores line items").

  2. 2
    Underline

    Nouns → candidate data; verbs → candidate behaviour. Two columns, both labelled candidate.

    fails by Every noun becomes a class on the spot.

  3. 3
    Sort the nouns

    State this concept holds (items); a reference to another's state (productId); an actor (customer); a computation (total).

    fails by The actor gets fields; the computation gets stored.

  4. 4
    Place the verbs

    Each on the concept whose state it changes; reads stay reads; verbs that change another concept's state move there.

    fails by The grammatical subject owns the method — Customer.add.

  5. 5
    Examples

    Two or three before/after cases add what the sentence never said (quantity) and demote what it did (total).

    fails by Skipped; the first missing field is found by a bug.

Where each word went

The words of the record's sentences, with their fates. Two of the rows are the heuristic working; three are it being corrected — by the boundary, by the examples, or by the state canvas.

WordHeuristic saysBecameDecided by
Cart (noun)datathe concept; state = itemsthe sentence — it is the thing being defined
Product (noun)dataa reference: items[].productIdthe boundary — the catalog owns the product
Customer (noun)dataan actor; an owner id from V1, absent in V0the boundary and the version
adds (verb)behaviouraddItem(cart, productId, quantity) on the cartthe state it changes
total (noun)dataan operation: total(cart, priceOf)the state canvas — computable every time
— (not in the sentence)items[].quantitythe example "add Laptop again → Laptop × 2"

The claim "every noun is a class"

The heuristic's strong form, run through the why ladder. It is not wrong so much as answering an easier question than the one you have; the real requirement is a first list, and the simpler thing is a labelled list of candidates.

Why ladder

Every noun in the sentence should become a class, and every verb a method on it.

  1. Why a class per noun? So that the code mirrors the domain and nothing in the sentence is lost.
  2. Why does mirroring the sentence matter? So a reader of the code can recognise the concept — the cart, the product, the customer.
  3. Why would a class per noun fail that? Because the sentence omits state the concept needs (quantity) and includes nouns that are not state (total, customer); mirroring it produces a model that is both missing things and carrying things.
  4. Why then use the heuristic at all? Because a blank sentence has no starting point, and a list of candidates is one — as long as the examples get the final say.
real requirement A first list of things that might need remembering and things that might happen, produced fast enough to start writing examples about.
simpler Underline, sort by boundary, place verbs by the state they change, then let two examples add and remove entries.

the claim was right when The sentence is already a refined domain statement — written after examples, in a vocabulary the team has agreed on — so that its nouns *are* the entities and its verbs *are* the operations. Then the mapping is close to one-to-one, and the heuristic is simply reading the design back.

The implementation ladder

Concept, examples, pseudocode, code, tests, production — for the concept this lesson is about. Code is the fourth tab, not the first.

concept Shopping Cart beginner
Build it step by step →

Shopping Cart = A temporary collection of products the user intends to purchase, held between browsing and checkout.

Identity, ownership, lifetime
  • 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.
State it must remember
  • 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.
Operations
  • 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
Rules that must always hold
  • 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, underline nouns and verbs, and produce two columns headed "candidate data" and "candidate behaviour" — the word candidate is doing work.
  • Sort each noun: state this concept holds, a reference to state another concept holds, or an actor. Only the first becomes fields.
  • Attach each verb to the state it changes, not to its subject; a verb that changes nothing is a read, and a verb that changes another concept's state belongs to that concept (CRUD and Domain Actions).
  • Run two or three examples and add the nouns they reveal; demote any noun no example needs to store (Derived vs Stored).
  • Say out loud where the heuristic misled you this time — it always does somewhere — so the next person does not trust it more than it deserves.

Worked on a concrete problem

The move has to produce something. This is what it produced.

  • "A customer adds products to a cart." Nouns: Customer → actor (an owner id from V1, never a cart field in V0); Product → a reference, productId, because the catalog owns the product; Cart → the concept itself, whose state is items. Verb: adds → addItem(cart, productId, quantity), on the cart, because that is what changes. The sentence yielded one field and one operation, and the second field — quantity — came from the example "add Laptop again → Laptop × 2".
  • "The customer sees the total." Noun: total. Heuristic says field; the state canvas asks "can it be computed every time it is needed?" — yes, a short loop over items and catalog prices — and drops it. The noun became the operation total(cart, priceOf). A noun that is a computation is the heuristic's most common miss.
  • "The customer removes a product." Verb: removes → removeItem, on the cart. The sentence does not say what happens when the product is not there; the invalid example does, and V1 chooses a no-op. The verb gave the operation; the example gave its contract (Operation Contracts).

How you know it worked

What now exists that did not before, and what question you can now ask.

  • Two columns exist, headed candidate data and candidate behaviour, and each noun carries a fate: state, reference, actor, or computation.
  • Every operation sits on the concept whose state it changes, and you can say why addItem is not Customer.add.
  • The list has entries the sentence did not contain — quantity — and lacks entries it did — total as a field — and both differences have a reason written beside them.

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.

Next questions
  • ?Which nouns in the sentence are state this concept holds, which are references to another concept's state, and which are actors?
  • ?For each verb, what state does it read and what does it change — and does it belong here?
  • ?Which nouns are computations wearing a noun's clothing?
  • ?What did the examples reveal that the sentence never said?

What can go wrong

How the move itself fails
  • The heuristic is applied to a paragraph instead of a sentence and produces fifteen classes, including Browsing and Checkout as nouns with no state.
  • It is applied once and trusted. The columns are never checked against examples, so "quantity" is discovered by a bug and "total" by a sync error.
  • It is rejected entirely because it is "just grammar", and the learner faces the blank sentence with no way to start. The move is a way to start, not a way to finish.
What the move costs
  • The heuristic is fast and gives a learner a first list in minutes; it also gives them a false sense that the list is complete.
  • Attaching verbs to the state they change produces a cart with behaviour and a customer with almost none, which is right for the domain and can look odd to someone expecting a class per noun.
  • Treating every product as a reference means every render is a catalog lookup, which is the correct V0 choice and a cost that a later version may cache.
Misreads
  • "Nouns become classes and verbs become methods." As a law it is wrong in both directions: "total" is a noun and a method, "quantity" is absent and a field, and the actor noun is not a class in the cart at all. As a way to produce candidates it is fine — the precise, falsifiable form is "nouns are candidates for data and verbs for behaviour; the examples decide."
  • "The subject of the verb owns the method." The state that changes owns the operation. Customer.addToCart(cart, product) is grammatical and puts the cart's rules on the customer.
  • "If the heuristic misleads, use a real methodology instead." Every method for finding a first list — event storming, CRC cards, user stories — is a heuristic with a different blind spot. The move is to know the blind spot, and this one's is computed nouns and unsaid state.

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.

  • GENERALProducing candidates from the sentence and sorting nouns into state, reference, actor and computation works for any concept described in a sentence — a message in a chat, a job in a queue — and the blind spots are the same.
  • CONTESTEDThe noun/verb heuristic is itself disputed. Some practitioners hold that it is actively harmful — that it produces anemic models, one class per noun and behaviour on the wrong object, and that a first list should come from behaviour, events or examples instead. Their strongest point is that the record's own state (quantity) and its most important rule were found by examples, not by grammar. The lesson's answer is that examples need something to be examples *of*, and the heuristic is the cheapest way to get a first noun to write an example about, provided it is labelled a candidate list.
  • ILLUSTRATIVEThe sentences, the laptop and the fifteen classes are invented to show the heuristic's hits and misses; no real store's domain model is described.

Where the depth lives

This domain asks the question and hands the answer off by name.