领域驱动设计

核心立场：DDD 不是一套建模技巧集合，而是一种在复杂业务系统中，通过语言、边界与模型压缩认知复杂度、协调组织协作的系统性方法论。

DD分层与六边形架构与整洁架构

一、第一性原理层（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）

聚合 = 一致性与不变性的最小边界

核心原则：

  1. 只通过聚合根访问
  2. 聚合内强一致
  3. 聚合之间最终一致
  4. 聚合要“小而自洽”

4. 领域服务（Domain Service）

5. Repository & Factory

二者的本质区别在于：创建 vs 已存在对象的获取

五、边界与协作层（Boundary）——如何在组织中保持一致性

1. 限界上下文（Bounded Context）

限界上下文 = 语言与模型的生效范围

2. 上下文映射（Context Mapping）

上下文关系 = 组织协作关系

场景推荐策略
强协作、强控制Shared Kernel
受制于外部ACL
收益低Separate Ways
服务化输出Open Host Service

六、演进与重构层（Evolution）——模型如何随认知成长

1. 重构的本质

DDD 重构 = 模型认知升级，而非代码洁癖

触发信号：

2. 从隐式到显式

3. 突破与风险

七、战略设计层（Direction）——长期竞争力的来源

1. 核心域（Core Domain）

核心域 = 组织最值得投入认知与人才的地方

2. 精炼与分离策略

八、适用边界与常见误区

1. DDD 不解决的问题

2. 常见误区

九、总结：DDD 的真正价值

DDD 的终极价值不在于“代码长什么样”，而在于：

关联内容（自动生成）