Appearance
Day 03 - 战略设计：通用语言与领域建模
📖 今日目标
- 理解通用语言（Ubiquitous Language）的概念
- 掌握如何建立和维护通用语言
- 学习领域建模的基本方法
核心概念
什么是通用语言？
通用语言（Ubiquitous Language） 是DDD的核心实践之一，它是一套在团队中共享的、精确的业务术语体系。
用通用语言说话、写作、设计、编码，让团队沟通无歧义
通用语言的特点：
- 普遍性：团队全员（开发、业务、测试）都在使用
- 精确性：每个术语有且只有一种含义
- 持续性：贯穿整个项目生命周期
领域建模
领域建模 是将业务知识转化为可执行的软件模型的过程。
模型需要反映：
- 业务实体及其关系
- 业务规则和约束
- 业务流程和状态变更
关键要点
1. 通用语言的创建过程
1. 与业务专家对话，识别关键术语
2. 记录术语及其定义，建立词汇表
3. 用术语绘制模型图
4. 在代码中实现模型
5. 用术语进行所有沟通
6. 持续更新和演进2. 识别核心领域词汇
常见的领域词汇类型：
- 实体名称：订单、客户、商品、库存
- 动词：下单、支付、退款、取消
- 业务规则：满100减10、新用户首单优惠
- 状态：待支付、已支付、已完成、已取消
3. 避免模糊术语
问题示例：
- ❌ "处理" → 具体是什么处理？计算？验证？转换？
- ❌ "业务" → 哪些业务？
- ❌ "用户相关" → 用户ID？用户信息？用户权限？
改进示例：
- ✅ "计算订单总价"
- ✅ "订单管理"、"用户管理"
- ✅ "读取用户基本信息"
4. 模型与代码的一致性
模型不是一成不变的图，而是团队对业务的共同理解：
- 模型驱动设计：模型指导代码实现
- 代码反馈模型：代码改变时更新模型
- 持续对话：模型是团队沟通的工具
5. 领域建模的输出物
| 输出物 | 说明 |
|---|---|
| 领域词汇表 | 术语定义及其对应关系 |
| 领域模型图 | 实体、值对象、聚合、领域事件 |
| 限界上下文图 | 上下文边界及映射关系 |
| 业务流程图 | 关键业务场景 |
面试考点
问题1：为什么DDD强调通用语言？
答案：
DDD强调通用语言的核心原因在于解决沟通问题：
消除歧义：
- 业务说"订单"可能指待支付订单
- 开发理解"订单"可能指数据库表
- 通用语言让"订单"有明确含义
降低翻译成本：
- 传统模式：业务语言 → 技术语言 → 代码
- 通用语言：直接使用统一语言，减少翻译损失
促进团队协作：
- 通用语言让业务专家能参与技术讨论
- 模型图成为团队的共同语言
代码可读性：
- 代码中的命名直接反映业务概念
- 新成员更容易理解系统
支持领域发现：
- 在建立通用语言过程中会发现业务盲点
- 推动对业务的深入理解
问题2：如何发现领域模型？
答案：
发现领域模型是一个迭代过程，常用方法：
事件风暴（Event Storming）：
- 识别领域事件（Domain Event）
- 从事件倒推触发事件的原因和涉及的实体
- 发现聚合和限界上下文
对话挖掘：
- 与业务专家频繁交流
- 记录反复出现的术语和场景
- 识别高频业务操作
现有文档分析：
- 分析需求文档、用例文档
- 提取关键名词和动词
- 识别业务规则
现有系统逆向：
- 分析现有数据库结构
- 识别核心业务流程
- 发现模型和问题区域
命名验证：
- 模型名称是否与业务专家的认知一致？
- 是否存在一词多义或一义多词？
- 术语是否在团队中达成共识？
实践思考
🎯 思考题：
以"用户下单"场景为例：
- 列出所有涉及的业务术语
- 为每个术语给出精确定义
- 识别可能存在歧义的术语
- 尝试画出这个场景的领域模型简图
📚 扩展阅读
- 《领域驱动设计》第2章：交流与语言的使用
- 《事件风暴》- Alberto Brandolini
- Domain Language Making Meaning Explicit
📅 学习进度
| Day | 主题 | 状态 |
|---|---|---|
| 01 | DDD初识：什么是领域驱动设计 | ✅ |
| 02 | 战略设计：限界上下文与上下文映射 | ✅ |
| 03 | 战略设计：通用语言与领域建模 | ✅ |
| ... | ... | ... |
| 30 | 复习与总结 | ⬜ |