World Map · 工程方法论蒸馏

L1 - 入门：为什么要 DDD ​

DDD 解决什么？什么时候用？什么时候不用？——回答"我应不应该学 DDD"的入门章。

一句话 ​

DDD = 业务领域驱动设计的协作方法论——不是技术框架。业务复杂 + 多团队协作 + 战略价值 → 用 DDD。简单 CRUD + 单团队 → 不必 DDD。

这本书在这一层说了什么 ​

本层基于 IDDD Ch 1 完整精读（89KB / 14460 词）。

Vernon Ch 1 开篇：

"You can implement DDD if you have • A passion for creating excellent software every day • The eagerness to learn and improve • The aptitude to understand software patterns • The skill and patience to explore design alternatives • The courage to challenge the status quo • The desire and ability to pay attention to details"

Vernon 关键洞察：

"DDD isn't first and foremost about technology. In its most central principles, DDD is about discussion, listening, understanding, discovery, and business value, all in an effort to centralize knowledge."

核心论点 4 个：

  1. Can I DDD? — 你能 DDD 吗？
  2. Why You Should Do DDD — 为什么 DDD
  3. How to Do DDD — Ubiquitous Language
  4. The Challenges of Applying DDD — DDD 的挑战

是什么 ​

1. Can I DDD?（你能 DDD 吗？） ​

Vernon 列举的"你能 DDD" 7 大特征：

1. 对创造卓越软件的热情 + 实现目标的韧性
2. 渴望学习改进 + 承认不足的勇气
3. 理解软件模式 + 正确应用的能力
4. 用敏捷方法探索设计替代方案的技能 + 耐心
5. 挑战现状的勇气
6. 关注细节 + 实验发现的渴望与能力
7. 寻求更聪明更好代码的动力

Vernon 关键论断：

"I'm not going to tell you that there isn't a learning curve. To put it bluntly, the learning curve can be steep."

关键提醒：DDD 学习曲线陡峭。

2. 业务专家不是按"职位"判断 ​

Vernon 关键论断：

"A domain expert is not one by job title. These are the people who know the line of business you are working in really well. They probably have a lot of background in the business domain, and they might be product designers or even your salespeople."

实战判断：

  • 业务专家 = 业务领域知识最丰富的人
  • 可能是产品设计师、销售、客服、运营
  • 不是必须有"业务专家"职位

Vernon 建议：

"Look past the job title. The people you are looking for know more about what you are working on than anyone else. Find them. Listen. Learn. Design in code."

3. Why You Should Do DDD（为什么 DDD） ​

Vernon 关键洞察：

"Delivering Business Value Can Be Elusive."

根因：

  • 软件开发者不懂业务
  • 业务专家不懂软件
  • 沟通鸿沟 → 交付失败

Vernon 的"贫血病与失忆症"诊断：

"Anemia and Memory Loss."

贫血症 = 模型只是数据袋（getter/setter）→ 业务逻辑散落 失忆症 = 系统忘记业务规则 → 用户体验差

DDD 的解决：

  • 模型 = 业务逻辑 + 状态
  • 系统 = 业务规则的实现

4. Ubiquitous Language（通用语言） ​

Vernon 关键洞察：

"If you are capable of understanding the business in which your company works, you can at a minimum participate in the software model discovery process to produce a Ubiquitous Language."

Ubiquitous Language 3 大规则：

1. 团队共同语言（业务 + 技术 + 设计）
2. 代码用业务术语命名（不用技术翻译）
3. 文档 / 代码 / 沟通都用同一语言

反模式：

  • 业务说"订单"代码叫 OrderVO → 沟通鸿沟
  • 业务说"客户"代码叫 UserEntity → 沟通鸿沟

5. The Business Value of Using DDD（DDD 的 8 大商业价值） ​

Vernon 列举：

#价值含义
1Organization Gains a Useful Model of Its Domain组织获得有用的业务模型
2Refined, Precise Definition and Understanding of the Business业务定义精确化
3Domain Experts Contribute to Software Design业务专家参与设计
4Better User Experience更好的用户体验
5Clean Boundaries around Pure Models清晰的模型边界
6Better Enterprise Architecture更好的企业架构
7Agile, Iterative, Continuous Modeling敏捷迭代持续建模
8New Tools, Strategic and Tactical新的战略战术工具

Vernon 关键洞察：

"If you give it a chance, DDD makes that possible."

6. The Challenges of Applying DDD（DDD 的挑战） ​

Vernon 关键警告：

"Justification for Domain Modeling."

挑战 1：业务建模的论证

  • DDD 早期投入大
  • 业务看不到短期回报
  • 工程师需要说服业务

挑战 2：DDD 不重

"DDD Is Not Heavy."

Vernon 论断：

"DDD doesn't have to be heavy. You can apply DDD as a series of small, focused projects, with each one delivering business value."

关键：DDD 可以渐进式应用，不是一蹴而就。

为什么 ​

为什么 DDD 是"协作方法论"不是"技术框架"？ ​

Vernon 关键论断：

"DDD isn't first and foremost about technology. In its most central principles, DDD is about discussion, listening, understanding, discovery, and business value."

根因：

  • 技术框架可以买（Spring, Axon, ...）
  • 业务理解不能买（必须协作）
  • Ubiquitous Language 不能工具化（必须人参与）

DDD 的核心是"协作"——技术是工具，协作是核心。

为什么业务专家参与设计？ ​

Vernon 关键论断：

"The domain experts don't know everything about their business, and they are also going to learn more about it. Just as you are going to learn from them, there is a high probability that they are also going to learn from you."

根因：

  • 业务专家懂业务但不反思业务
  • 开发者的提问往往揭示业务盲点
  • 协作 = 双方都学到新东西

为什么 Ubiquitous Language 重要？ ​

反例（无通用语言）：

  • 业务说"用户"代码叫 User → 业务讨论时用"用户"，代码 review 时用 User → 沟通鸿沟
  • 业务说"会员"代码叫 Member → 不知道 User = Member → 沟通鸿沟

有通用语言：

  • 业务说"用户"代码叫 User → 完全一致
  • 业务说"客户"代码叫 Customer → 完全一致
  • 命名变更 = 业务变更同步

怎么做 ​

Step 1：评估"是否 DDD" ​

决策矩阵：
  Q1: 业务复杂度？
    高 → DDD 候选
    低 → 不必 DDD
    
  Q2: 团队规模？
    多团队 → DDD 价值高
    单团队 → DDD 价值有限
    
  Q3: 战略价值？
    核心业务 → DDD 投资值得
    通用业务 → 不必 DDD

Step 2：建立 Ubiquitous Language ​

操作：
  1. 业务专家 + 开发聚集工作坊
  2. 列出业务核心术语
  3. 每个术语达成共识（业务定义 + 技术映射）
  4. 写入 Glossary 文档
  5. 代码命名严格用业务术语

Step 3：渐进应用 DDD ​

Vernon 建议：
  DDD 不必一次到位
  - 第一步：识别核心域 + 战略设计
  - 第二步：在核心域内做战术设计
  - 第三步：扩展到其他 BC
  
每步交付业务价值 → 业务看到回报 → 继续投入

什么时候用 / 什么时候不用 ​

用 DDD 的 2 大场景 ​

场景关键判断
业务复杂 + 多团队 + 核心业务DDD 价值最高（投入回报 > 1）
业务变化频繁 + 需要快速演化DDD 的战略设计让演化更清晰

不用 DDD 的 2 大场景 ​

场景原因
简单 CRUD + 单团队DDD 是过度工程
初创期快速迭代 + 业务未稳定DDD 早期投入大，业务可能反复变

Vernon 关键警告：

"Misappropriated use happens far more often than many are aware. Often a concept should be modeled as a Value. If this is a disagreeable notion, it might be that DDD doesn't fit your business needs. It is quite possible that a CRUD-based system would be more fitting."

CRUD 适用场景（Vernon 论断） ​

"Businesses regularly put too much effort into developing glorified database table editors... When CRUD makes sense, languages and frameworks such as Groovy and Grails, Ruby on Rails, and the like make the most sense."

判断：业务 = 数据库表编辑 → CRUD 够用，不必 DDD。

看不见的地方 ​

失效模式 1：把 DDD 当技术框架 ​

症状：引入 Axon / EventStorming 就以为在做 DDD。

根因：忽略 DDD 是"协作方法论"非"技术栈"。

修复：DDD 的核心是"业务 + 技术团队对话"，技术框架只是辅助。

失效模式 2：跳过战略设计直接做战术 ​

症状：上来就设计实体、值对象、聚合 → BC 边界错误 → 后期重构。

根因：未做"域、子域、限界上下文"战略划分。

修复：先战略后战术，先 BC 边界后实体设计。

失效模式 3：业务专家缺席 ​

症状：开发闭门造车设计领域模型 → 模型脱离业务。

根因：业务专家被当作"需求提供方"而非"建模合作方"。

修复：业务专家全程参与 EventStorming / 建模工作坊。

失效模式 4：过度建模 ​

症状：CRUD 业务也用聚合根 + 领域事件 → 复杂度爆炸。

根因：DDD 不是"处处适用"，核心域才需要 DDD。

修复：判断子域类型（核心/支撑/通用），只在核心域用 DDD 全套。

失效模式 5：团队不学习通用语言 ​

症状：代码命名（OrderVO）与业务语言（订单）不一致 → 沟通鸿沟。

根因：通用语言停留在文档，未在代码中强制。

修复：代码命名严格用业务术语，CR 时审查命名。

失效模式 6：DDD 一次性大跃进 ​

症状：花 3 个月做战略设计但业务还没跑起来 → 错失市场。

根因：DDD 实施节奏错误。

修复：渐进应用——先核心域 → 交付价值 → 扩展到其他 BC。

相关节点 ​

骨架 A — 世界观 ​

节点关联解释
wonder-01-emergence-vision强DDD 战略设计 = "涌现视域"——业务空间是涌现的整体
wonder-02-emergence-action中DDD 战术设计 = "涌现作为"——实体/值对象/服务是作为单位

骨架 B — 工程实践 ​

节点关联解释
value-stream中Ubiquitous Language = 价值流语言——团队对齐语言 = 减少沟通成本

与 IDDD 其他层对位 ​

层关系
L2-L4战略设计（建立在 L1 "为什么 DDD" 之上）
L5-L8战术设计（建立在战略设计之上）

与海德格尔对位 ​

Vernon 的 Ubiquitous Language = 海德格尔的"语言是存在的家"：

  • 海德格尔：语言揭示存在
  • Vernon：通用语言揭示业务
  • 两者都是"通过语言让本质显现"

状态 ​

L1 概念递进落地完成（基于原书 ch01 89KB / 14460 词）。

  • 6 个核心论点（Can I DDD / 业务专家 / Why / Ubiquitous Language / 商业价值 / 挑战）
  • 6 个失效模式
  • 骨架 A/B + IDDD + 海德格尔完整映射

从名家方法论与工程化思路中蒸馏出自己的工程体系。

© World Map