01-领域与问题空间-DDD领域驱动设计

---

title: "01 领域与问题空间"

---

学习目标

• 能用自己的话解释：什么是领域（Domain），什么是模型（Model）
• 理解"问题空间（Problem Space）"与"解空间（Solution Space）"的区别
• 能把一段业务叙事提炼成：关键概念、关键规则、关键流程

核心概念

领域（Domain）

领域不是"系统功能列表"，而是业务问题空间：概念、规则、流程、约束、例外情况的集合。

模型（Model）

模型是对领域的"有选择的简化"，为了解决问题而保留必要信息，忽略无关信息。

问题空间 vs 解空间

• 问题空间：业务要解决什么？为什么难？规则是什么？例外是什么？
• 解空间：用什么技术实现？数据库怎么设计？接口怎么做？

DDD 的核心要求是：先把问题空间弄清楚，再进入解空间。

课堂讲授：从叙事到模型

给定一段叙事（示例）：

用户下单后，必须在 30 分钟内完成支付；超时系统自动取消订单。支付成功后才能发货。一个订单最多 50 个商品行。

提炼步骤（最小可用）：

1. 抽取名词（候选概念）：用户、订单、支付、发货、商品行、超时
2. 抽取动词（候选命令）：下单、支付、取消、发货
3. 抽取状态（候选状态机）：已下单、已支付、已取消、已发货
4. 抽取不变量/约束：30 分钟、最多 50 行、支付后才能发货

伪代码示例：把约束写到模型里

Aggregate Order
  state: Created | Paid | Cancelled | Shipped
  invariant:
    - only Created can addLine
    - lineCount <= 50
    - only Paid can ship
    - only within 30m can pay (or else auto-cancel)

常见误区

• 把数据库表当模型：表结构无法表达规则与例外，最终规则散落在各处
• 把"接口字段"当模型：字段再全，也不等于业务语义

课堂练习

给你一个业务叙事（你可以用自己项目的任意一段），输出：

• 10 个候选名词
• 5 个候选命令（祈使式）
• 5 个候选领域事件（过去式）
• 3 条最关键不变量（必须一直成立）

自测题

1. 为什么模型一定是"有选择的简化"，而不可能把领域完整复制进代码？
2. "订单最多 50 行"更像是需求、约束，还是领域事件？为什么？
3. 如果一个规则散落在 Controller、Service、SQL 三处，会导致什么后果？

延伸阅读

参考资料索引：references.md