Home / Skills / Developer Productivity / Domain Modeling
Developer Productivity

Domain Modeling

Matt PocockMITSkill language: English
License verifiedNo scripts
DemoReal run · claude-opus-5-5 · October 2026
Our team keeps tripping over two words. "Account": in support tickets it sometimes means the company that pays us and sometimes the person who logs in. In the code, `Order.account_id` points at the paying company. "Cancelled": when an order has one line already shipped, support says they "cancel" the rest of the order, but the code refuses to cancel an order with shipped lines, so support ends up issuing a refund by hand. Help me pin these terms down for this project and record what we decide.
Skill: domain-modeling
Read: .claude/skills/domain-modeling/GLOSSARY-FORMAT.md
Read: GLOSSARY.md
Read: GLOSSARY-MAP.md
Read: src
Read: .claude/skills/domain-modeling/ADR-FORMAT.md
Read: src/ordering
Read: src/order.py
Read: src/models.py
Read: src/orders.py
Read: README.md
Edit: GLOSSARY.md

I added Customer and User to GLOSSARY.md, with "Account" on the avoid list for both. Order.account_id in src/orders.py:21 still uses the old word. Renaming it to customer_id would bring the code in line with the glossary, and I can do that if you want. I left the code alone for now because the rename may affect the database and any APIs that use the field.

One question on User: can one person log in for more than one Customer, for example a consultant who orders for two of your clients? If yes, then "User belongs to a Customer" is wrong, and the definition needs to say so.

"Cancelled": this needs a decision from you

The code and support are using one word for two different actions:

  • Code (src/orders.py:25-28): cancelling applies to the whole Order, and it's refused if any line has shipped.
  • Support: "cancel" also means "stop the lines that haven't shipped yet and refund them," on an Order that stays partly delivered.

Here's a scenario to test the options. An Order has 3 lines: line A has shipped, and lines B and C haven't. The Customer says, "Don't send the rest."

  1. What happens to the Order? Is its status CANCELLED even though line A was delivered and paid for? Or does it count as complete (just A), with B and C individually cancelled? Today the code only has PLACED / SHIPPED / CANCELLED on the Order, and only a shipped flag on each line, so there's no way to record "B and C were cancelled."
  2. Is the refund part of the cancellation, or a separate thing? Support refunds by hand today. Should cancelling unshipped lines automatically trigger a refund for them, or is a Refund its own concept with its own rules (for example, it could also be used for damaged goods)?
  3. What if the Customer wants to cancel just line C and still get line B? If that should be allowed, the concept works per line, not as "the rest of the Order."

My recommendation: use two terms.

  • Order Cancellation: stopping an entire Order before any line has shipped. This is what the code already does.
  • Line Cancellation: stopping one or more unshipped lines while the rest of the Order goes ahead. A Refund for the cancelled lines follows from it.

Support would then say "cancel lines B and C," never "cancel the order," when something has already shipped. This also tells you what to change in the code: lines need their own cancelled state, and partial cancellation should no longer go through a manual refund.

Answer questions 1–3 (and the User question) and I'll add the cancellation terms to the glossary. If you go with per-line cancellation and automatic refunds, I'd also suggest a short ADR. Changing the Order/line state model is hard to undo, and someone reading the code later could reasonably wonder why Order.cancel() refuses partly shipped Orders when line cancellation exists.

Change recorded in the trial sandbox (git diff of GLOSSARY.md):

diff --git a/GLOSSARY.md b/GLOSSARY.md
index a218c96..a1a541a 100644
--- a/GLOSSARY.md
+++ b/GLOSSARY.md
@@ -7,3 +7,11 @@ Receives customer orders and tracks them until delivery.
 **Order**:
 A request from a Customer to buy one or more products, placed in a single checkout.
 _Avoid_: Purchase, basket
+
+**Customer**:
+The company that places Orders and pays us for them.
+_Avoid_: Account, client, company
+
+**User**:
+A person who logs in to act on behalf of a Customer.
+_Avoid_: Account, login, member

Real run recorded with claude-code / claude-opus-5-5. Run in a temporary directory with a sample glossary and order code. The last block is the git diff of GLOSSARY.md recorded when the trial ended. The model output is unmodified.

What it does

Actively builds and sharpens a project's domain model while you design, instead of only reading a glossary. It records terms and decisions the moment they are settled.

How it works

  1. Challenges terms that conflict with the existing glossary, and proposes one precise term for vague or overloaded words such as "account".
  2. Stress-tests relationships with invented edge-case scenarios and cross-checks what you say against the code, surfacing contradictions.
  3. Updates GLOSSARY.md inline: opinionated one or two sentence definitions with an "avoid" list, only for terms specific to your project.
  4. Offers ADRs sparingly: only when a decision is hard to reverse, surprising without context and the result of a real trade-off.
  5. Supports one glossary per repo or several contexts listed in a GLOSSARY-MAP.md.

Good for

Teams whose people, tickets and code use the same word for different things.

Worth knowing

In our trial it separated "Customer" from "User", then refused to guess on an open question and asked several clarifying questions instead.

Notes & risks

Pure instruction files: no scripts and no network access. The skill tells the agent to create and edit GLOSSARY.md (or GLOSSARY-MAP.md) and docs/adr/ files in your repository, and it reads your code to cross-check what you say. The package also contains the original MIT LICENSE and agents/openai.yaml (display name for Codex).