DDD 基础

学习目标

• 能解释“DDD 基础”如何通过领域专家与开发者持续协作，把知识消化为通用语言和可执行模型，并让代码表达同一套业务含义
• 能逐项定位 领域、模型、通用语言、知识消化、模型驱动设计，并说明每个概念在当前来源边界内承担什么责任
• 能按 收集关键案例 → 暴露语言冲突 → 提炼模型 → 写入代码与测试 → 由专家复核结果 推演“退款资格”，检查“对话、文档、模型和代码中的关键术语保持同义；新知识出现时四者一起演化”
• 能注入“先设计通用技术框架，再把业务名词贴到贫血数据对象和 CRUD 服务上”，依据领域对话记录、术语变更、模型草图、规则示例、代码命名与领域专家验收定位越界、撤销并用同一情境重放

为什么从“从最难、最有区分度的领域问题开始共同建模，让语言、模型与实现形成可被反例修正的同一系统”开始

通过领域专家与开发者持续协作，把知识消化为通用语言和可执行模型，并让代码表达同一套业务含义。本页先画责任和依赖，再沿具体情境执行决策，最后主动制造一个边界违规；这种顺序把术语变成可以验证、推翻和恢复的设计合同。

“DDD 基础”不是技术采购建议。它处理的是规则放在哪里、模型在哪个语境内成立、哪些变化可以被隔离，以及团队如何判断一条边界已经被穿透。最终功能可运行，只能证明快乐路径存在，不能证明结构允许安全演进。

来源、版次与课程边界

术语与模式摘要采用 Eric Evans 官方 DDD Reference 的公开网页和 CC 授权 PDF；Pearson 原书页仅核对第一版身份，正文为独立教学重写。

本专题不是某一本既有书的中文版，也不是把多位作者的文章拼成“原著章节”。课程主干分别取自 Eric Evans 的领域驱动设计体系与 Robert C. Martin 的整洁架构体系；CQRS、事件溯源和六边形架构始终标为扩展。以下链接承担不同事实责任：

• Pearson: Domain-Driven Design：核对 Eric Evans、第一版、出版信息与原书身份，不据此声称拥有全文
• Eric Evans: Domain-Driven Design Reference：核对 DDD 定义、模式摘要、增补范围与 CC 授权说明
• Domain-Driven Design Reference PDF：核对分层、限界上下文、战术模式和上下文映射的公开摘要正文

本页采用独立中文重写。能从公开全文或授权摘要核对的定义才作为来源事实；项目情境、交互实验、取舍表和练习答案均为本站教学设计。

核心概念与可观察责任

领域

领域是软件要服务的活动和知识范围；DDD 优先投入复杂而有业务差异的核心领域，而非把所有模块同等复杂化。 在“退款资格”中，观察重点是对话、文档、模型和代码中的关键术语保持同义；新知识出现时四者一起演化。

模型

模型是为解决特定问题而选择性简化的知识表达，不是现实世界的完整复制；有用性取决于它支持哪些判断和行为。 在“同名客户”中，观察重点是领域对话记录、术语变更、模型草图、规则示例、代码命名与领域专家验收。

通用语言

团队在一个模型边界内共同使用精确语言，并把它用于讨论、图示、测试和代码；含糊与冲突会直接暴露模型缺陷。 在“退款资格”中，观察重点是对话、文档、模型和代码中的关键术语保持同义；新知识出现时四者一起演化。

知识消化

开发者与领域专家通过例子、矛盾和重构反复提炼知识，不是一次需求访谈后由分析文档向下传递。 在“同名客户”中，观察重点是领域对话记录、术语变更、模型草图、规则示例、代码命名与领域专家验收。

模型驱动设计

软件设计的关键结构应忠实表达模型，让代码运行结果反过来检验模型；模型与实现分离会使两者同时失去可信度。 在“退款资格”中，观察重点是对话、文档、模型和代码中的关键术语保持同义；新知识出现时四者一起演化。

一条可执行的设计判断

本页采用以下判断链：从最难、最有区分度的领域问题开始共同建模，让语言、模型与实现形成可被反例修正的同一系统。正常情况下必须持续保持“对话、文档、模型和代码中的关键术语保持同义；新知识出现时四者一起演化”；反例“先设计通用技术框架，再把业务名词贴到贫血数据对象和 CRUD 服务上”只改变一个关键条件，便于定位因果。

观察项	本页合同
最小正常情境	客服说“已完成订单”仍可能在特殊窗口内退款
边界或迁移情境	销售与风控对“客户”的识别范围和生命周期不同
必须保持	对话、文档、模型和代码中的关键术语保持同义；新知识出现时四者一起演化
首要违规	先设计通用技术框架，再把业务名词贴到贫血数据对象和 CRUD 服务上
验收证据	领域对话记录、术语变更、模型草图、规则示例、代码命名与领域专家验收

先预测，再操作三个本页实验

⚡分步1 / 3

1. 1
2. 2
3. 3

实验一：边界与模型地图

操作前先预测“退款资格”里哪一侧拥有规则、哪一侧只是技术或协作细节。切换概念和情境后，检查“从最难、最有区分度的领域问题开始共同建模，让语言、模型与实现形成可被反例修正的同一系统”是否仍能解释三块区域的责任。

Boundary model

DDD 基础：边界与责任地图

通过领域专家与开发者持续协作，把知识消化为通用语言和可执行模型，并让代码表达同一套业务含义

切换最小情境

退款资格同名客户

定位正式概念

领域模型通用语言知识消化模型驱动设计

architecturedomaindesign-06 · 当前观察

领域：客服说“已完成订单”仍可能在特殊窗口内退款

区域 1领域知识

专家经验、规则、例外与业务目标

↓

区域 2共同模型

选择性表达并形成通用语言

↓

区域 3可执行设计

代码和测试直接体现模型

情境验收

修正状态语言与规则模型，而不是在控制器里追加孤立 if

上一步重置播放下一步

易错边界与取舍

练习与答案

练习

问题 1：概念—边界—证据对照。 完成以下逐项核对：

1. 领域：写出它所在的边界、允许的依赖方向、一个最小反例和一份可观察证据。
2. 模型：写出它所在的边界、允许的依赖方向、一个最小反例和一份可观察证据。
3. 通用语言：写出它所在的边界、允许的依赖方向、一个最小反例和一份可观察证据。
4. 知识消化：写出它所在的边界、允许的依赖方向、一个最小反例和一份可观察证据。
5. 模型驱动设计：写出它所在的边界、允许的依赖方向、一个最小反例和一份可观察证据。

查看答案

对每个概念先确定它属于业务政策、模型协作还是外部技术，再画允许的依赖方向。用“客服说“已完成订单”仍可能在特殊窗口内退款”建立正常基线，用“先设计通用技术框架，再把业务名词贴到贫血数据对象和 CRUD 服务上”作为单一反例，最后从领域对话记录、术语变更、模型草图、规则示例、代码命名与领域专家验收中找第一处不一致。

问题 2：最小情境推演。 怎样验证“退款资格”没有靠最终功能碰巧通过？

查看答案

按 收集关键案例 → 暴露语言冲突 → 提炼模型 → 写入代码与测试 → 由专家复核结果 保存每步状态，预期结果是“修正状态语言与规则模型，而不是在控制器里追加孤立 if”。最终输出之外，还要逐步确认“对话、文档、模型和代码中的关键术语保持同义；新知识出现时四者一起演化”；任一中间状态越界都应拒绝当前设计。

问题 3：替代方案与恢复。 注入“先设计通用技术框架，再把业务名词贴到贫血数据对象和 CRUD 服务上”后，怎样比较修复与更简单方案？

查看答案

先保留故障前的领域对话记录、术语变更、模型草图、规则示例、代码命名与领域专家验收，再记录首个越界位置。分别实施最小修复和删除多余模式的方案，用同一个“销售与风控对“客户”的识别范围和生命周期不同”重放；选择仍满足“先确认模型边界，不强迫两个含义合并成一个万能 Customer”且依赖更少的方案。

本页小结

• DDD 基础的核心判断是：从最难、最有区分度的领域问题开始共同建模，让语言、模型与实现形成可被反例修正的同一系统。
• 正常路径以“修正状态语言与规则模型，而不是在控制器里追加孤立 if”验收，不能只检查接口返回成功。
• 边界路径以“先确认模型边界，不强迫两个含义合并成一个万能 Customer”验收，并保存领域对话记录、术语变更、模型草图、规则示例、代码命名与领域专家验收。
• 如果“先设计通用技术框架，再把业务名词贴到贫血数据对象和 CRUD 服务上”仍可静默通过，说明边界只是图示，没有成为可执行约束。