ddd-design

单行摘要

引导用户从功能简介逐步形成领域模型草案：统一语言 → 限界上下文 → 聚合 → 关键事件。

适用场景

• 新功能尚无模型。
• 绿地项目开始构建领域层。
• 扩展现有系统，进入尚无模型的新业务领域。
• 用户明确要求“设计”“建模”或“架构”某个领域。

不适用场景

• 为已确定的模式生成代码 → 转交给 ddd-implement。
• 改造现有代码 → 转交给 ddd-refactor。
• 审查代码是否违反 DDD 原则 → 转交给 ddd-review。

核心内容

设计分为四个步骤。大部分价值来自前两步；语言和边界明确后，再进行后两步。

步骤 1 — 提炼统一语言。 请用户（或领域专家）用自己的话描述功能。逐字记录名词和动词。对于听起来过于技术化的术语（“实体”“记录”“DTO”）以及含义多变的英文单词，要提出质疑。参见 ddd-ubiquitous-language，了解相关方法。

步骤 2 — 勾勒限界上下文。 这个模型的边界在哪里？哪些模型不由我们负责？为上游和下游上下文命名。参见 ddd-bounded-context；了解上下文之间的关系，请参见 ddd-context-mapping。

步骤 3 — 识别聚合。 根据记录下来的名词，将在同一事务中共同变更的对象归为一组。每组都有一个根；外部代码只引用根。参见 ddd-aggregate。

步骤 4 — 为候选领域事件命名。 用过去时描述业务关心的已发生事件（OrderPlaced、RefundIssued）。这些事件揭示了聚合和上下文之间的连接点。参见 ddd-domain-event。

决策启发

• 将对话时间的大约 80% 用于语言和边界（步骤 1–2）。如果后续发现模型不合适，几乎总是因为步骤 1 过于仓促。
• 如果用户不愿意精确命名，这本身就是需要做的工作——礼貌地提出质疑。
• 草拟到此为止。本技能不产出代码；用户提出需求时，转交给 ddd-implement。

反模式

• 语言尚未明确，就直接开始定义实体和属性。
• “我们就把它放进一个大上下文里吧”——现在省下一次对话，日后却要付出拆分上下文的代价。
• 同时设计数据库架构——从架构出发的思维会扭曲模型。
• 还没提到任何动词，就先画出类图。

另请参阅

• ddd-ubiquitous-language — 每次设计会话的第一项交付成果。
• ddd-bounded-context — 模型的边界。
• ddd-context-mapping — 与相邻模型之间的关系。
• ddd-aggregate — 按事务一致性对实体进行分组。
• ddd-domain-event — 连接聚合和上下文的连接点。
• ddd-subdomain-classification — 这个领域是否值得深入建模？

参考资料

• Evans，《领域驱动设计》（2003），第一部分（第 1–3 章）和第四部分（第 14–15 章）。