DDD 不是银弹，但在复杂业务域中它确实能帮你理清边界。以电商订单域为例，从战略设计到战术设计完整落地。

一、DDD 核心概念速览

  • 1.1 战略设计——限界上下文、上下文映射
  • 1.2 战术设计——聚合、实体、值对象、领域服务、仓储
  • 1.3 领域事件——事件驱动

二、战略设计——事件风暴

  • 2.1 识别领域事件——“订单已创建”、”订单已支付”、”订单已发货”
  • 2.2 识别命令——“创建订单”、”支付订单”
  • 2.3 识别聚合——Order 聚合、Product 聚合
  • 2.4 划定限界上下文——订单上下文、商品上下文、支付上下文、用户上下文

三、上下文映射

  • 3.1 订单上下文 ↔ 商品上下文——防腐层（ACL）
  • 3.2 订单上下文 ↔ 支付上下文——发布/订阅
  • 3.3 订单上下文 ↔ 用户上下文——共享内核

四、战术设计——Order 聚合

  • 4.1 聚合根——Order
  • 4.2 实体——OrderItem
  • 4.3 值对象——Address、Money、OrderNo
  • 4.4 领域服务——OrderDomainService
  • 4.5 仓储——OrderRepository

五、代码结构

  • 5.1 包结构——order/domain、order/application、order/infrastructure、order/interfaces
  • 5.2 Domain 层——纯 POJO，零依赖
  • 5.3 Application 层——编排领域对象
  • 5.4 Infrastructure 层——仓储实现、RPC 调用
  • 5.5 Interfaces 层——Controller、DTO

六、DDD 与微服务的结合

  • 6.1 一个限界上下文对应一个微服务
  • 6.2 领域事件驱动跨服务协作
  • 6.3 CQRS——读写分离

七、DDD 的取舍

  • 7.1 简单 CRUD 不需要 DDD
  • 7.2 DDD 的学习成本和团队共识
  • 7.3 可以局部使用——只对核心域用 DDD

八、总结

  • DDD 帮你把业务逻辑放在该放的地方——Domain 层
  • 好的 DDD 实践让代码即文档