首页 / Skills / 开发提效 / 领域建模 Domain Modeling
开发提效

领域建模 Domain Modeling

Matt PocockMITSkill 语言: 英文
协议已核对不含脚本
演示真实运行记录 · claude-opus-5-5 · 2026年10月
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.

它做什么

在你做设计的同时,主动建立并打磨项目的领域模型,而不只是读一遍术语表。术语和决定一旦敲定就立刻记录。

工作方式

  1. 质疑术语: 与现有术语表冲突的用法会被立即指出;对"account"这类含糊或一词多义的词,提出一个精确的标准说法。
  2. 压力测试: 虚构边界情况来检验各概念之间的关系,并把你的说法与代码核对,找出矛盾。
  3. 就地更新 GLOSSARY.md: 用一到两句话的明确定义,并列出"避免使用"的说法,只收录你项目特有的术语。
  4. 谨慎建议 ADR: 只有决定难以撤销、缺少背景会令人费解、且确实是权衡取舍的结果时才提出。
  5. 支持每个仓库一份术语表,或用 GLOSSARY-MAP.md 列出多个上下文。

适合场景

人、工单和代码对同一个词各有说法的团队。

需要了解

我们试用时,它把"Customer"和"User"区分开来,对一个悬而未决的问题没有擅自猜测,而是追问了几个澄清问题。

说明与风险

纯指令文件:没有脚本、不联网。 Skill 会让代理在你的仓库里创建并修改 GLOSSARY.md(或 GLOSSARY-MAP.md)和 docs/adr/ 下的文件,并读取你的代码来核对你的说法。 压缩包里另有原仓库的 MIT 协议文件 LICENSE 和 agents/openai.yaml(供 Codex 使用的显示名)。