领域驱动设计
核心立场：DDD 不是一套建模技巧集合，而是一种在复杂业务系统中，通过语言、边界与模型压缩认知复杂度、协调组织协作的系统性方法论。
一、第一性原理层（Why）——DDD 为什么存在
1. 复杂系统的根本矛盾
- 业务复杂度随时间 不可逆增长
- 人类个体认知能力 强约束
- 团队协作导致 认知分裂与语义漂移
DDD 的根本问题： 如何在长期演进的复杂系统中，让多个角色对“系统是什么、在做什么”保持一致理解。
2. DDD 的第一性原理
| 原理 | 本质解释 |
|---|---|
| 语言即模型 | 语言是认知的载体，不一致的语言必然导致不一致的系统 |
| 边界先于实现 | 不清晰的边界会放大复杂度 |
| 不变性优先 | 稳定的不变性是系统演进的锚点 |
| 模型是认知压缩 | 好模型 = 用更少概念表达更多规则 |
| 架构是组织的映射 | 系统结构反映沟通结构（Conway 定律） |
二、认知与语言层（What）——我们如何理解业务世界
1. 领域（Domain）
领域 = 一个被语言和规则定义的问题空间
- 不是“系统边界”
- 而是“业务问题的认知边界”
2. 子域（Subdomain）
子域是对领域的问题拆分方式：
| 子域类型 | 认知价值 | 战略意义 |
|---|---|---|
| 核心子域 | 差异化竞争力 | 投入最强人力 |
| 支撑子域 | 支持核心 | 可内部实现 |
| 通用子域 | 通用能力 | 可购买/外包 |
子域划分的本质：资源配置与注意力分配。
3. 通用语言（Ubiquitous Language）
通用语言 = 团队共享的业务世界观
- 业务人员、产品、研发使用同一组术语
- 语言变化 = 模型变化 = 系统变化
原则：
- 代码是通用语言的最终载体
- 文档仅用于解释“代码未表达的意图”
三、模型层（How）——如何构建可演化的认知结构
1. 模型的定义
模型 = 对现实知识的有意简化 + 结构化表达
模型的价值不在“是否完整”，而在：
- 是否帮助决策
- 是否约束行为
- 是否降低沟通成本
2. 有效建模的判定标准
| 维度 | 判定问题 |
|---|---|
| 可执行性 | 是否能指导代码结构？ |
| 表达力 | 是否自然表达业务规则？ |
| 稳定性 | 是否围绕不变性构建？ |
| 演化性 | 是否允许逐步精进？ |
3. 模型与实现的闭环
脱离实现的模型必然腐化
- 建模者必须参与编码
- 实现反向促进模型理解
四、战术设计层（Structure）——模型如何落地为结构
本层关注：在单一边界内，如何保持模型一致性
1. 实体（Entity）
- 由身份标识定义
- 拥有生命周期
- 业务行为应内聚于实体
2. 值对象（Value Object）
- 无身份
- 不可变
- 表达度量、描述、约束
3. 聚合（Aggregate）
聚合 = 一致性与不变性的最小边界
核心原则：
- 只通过聚合根访问
- 聚合内强一致
- 聚合之间最终一致
- 聚合要“小而自洽”
4. 领域服务（Domain Service）
- 表达跨实体但仍属于领域的行为
- 无状态
- 不应成为逻辑垃圾桶
5. Repository & Factory
- Factory：复杂对象/聚合的原子创建
- Repository：聚合的生命周期访问接口
二者的本质区别在于： 创建 vs 已存在对象的获取
五、边界与协作层（Boundary）——如何在组织中保持一致性
1. 限界上下文（Bounded Context）
限界上下文 = 语言与模型的生效范围
- 同名 ≠ 同义
- 上下文是语义的防火墙
2. 上下文映射（Context Mapping）
上下文关系 = 组织协作关系
| 场景 | 推荐策略 |
|---|---|
| 强协作、强控制 | 共享核心模型 |
| 受制于外部 | 防腐层 |
| 收益低 | 分开演进 |
| 服务化输出 | 定义标准化接口给外部 |
六、演进与重构层（Evolution）——模型如何随认知成长
1. 重构的本质
DDD 重构 = 模型认知升级，而非代码洁癖
触发信号：
- 新理解无法表达
- 隐式规则过多
- 模型开始僵化
2. 从隐式到显式
- 提炼概念
- 引入 Specification
- 将过程行为转为对象职责
3. 突破与风险
- 质变来自持续量变
- 模型突破往往意味着系统级调整
七、战略设计层（Direction）——长期竞争力的来源
1. 核心域（Core Domain）
核心域 = 组织最值得投入认知与人才的地方
- 高复杂度
- 高差异化
- 高回报
2. 精炼与分离策略
- Generic Subdomain：降级处理
- Segregated Core：增强内聚
- Abstract Core：抽象不变性
八、适用边界与常见误区
1. DDD 不解决的问题
- 性能极限
- 人员能力差异
- 需求本身不清晰
2. 常见误区
- 所有系统都用 DDD
- 战术设计替代战略思考
- 把 DDD 当成代码规范
九、总结：DDD 的真正价值
DDD 的终极价值不在于“代码长什么样”，而在于：
- 团队是否拥有一致的业务世界观
- 系统是否围绕不变性演进
- 组织是否通过模型降低了复杂度