总结

  • DDD就是个方法论，有点类似设计模式。总体需要面向接口编程。把业务和具体的三方实现、技术统统隔离开来。
  • 可以照着方法论设计出符合开闭原则的程序。降低新迭代的开发成本。减少维护成本。
  • 传统MVC就是1张表对应1个实体对应1个DAO对应一个service。
  • DDD拆service,不同的逻辑不要放一起，service按领域分、按功能分，不同service满足单一职责。
  • 领域下的service随时可以拉出去作为一个微服务。
  • 目标软件和业务统一。
  • 工作上产品和开发一起工作。
  • DDD与技术无关、与架构无关。
  • 2020年召开了DDD峰会，发布了菱形模型。有兴趣的同学可以关心下。
  • DDD的指导下，单体架构和微服务架构的统一，其实没啥区别的，区别就是本地方法和远程方法的调用方式。
  • DDD还有个好处，战略工具。管理上项目组扩张。

DDD 问题和不足

  • 学习成本高
  • 收效慢
  • 落地难，阿里有个cola4.0,但是行业里还没有普及。
  • DDD 是动态发展的。已经有10年了，正好微服务出来了后火了。

大型系统是如何变老的？

  • 沟通难：开发和产品会吵，谁说了算。
  • 开发难：代码腐朽了，开发人员换了好几波。
  • 测试难：牵一发动全身。
  • 创新难：创新难，新技术进入难。

微服务治标不治本。DDD被认为最理想化的方式。微服务+DDD的方法论。
开发人员上手难度低。小项目负责人可以给初级程序员。

DDD对标传统MVC。

  • 传统MVC代码很容易老化。
  • 数据库DAO改成 XXXXRepository 接口。应用不要直接从数据库那，问仓库要。业务只要数据，有效的隔离业务与底层存储的关系。
  • 实体和业务方法封装在一起，构成充血模型。对标POJO贫血模型。贫血失忆症。看着这个实体看不出这个实体是干嘛的了。
  • 实体和值对象，要访问值对象，必须通过实体来找。
  • 业务：DDD业务指造成实体状态变化的过程。
  • 通过防腐层，还改善第三方接口与业务的关系。
  • 把稳定的代码和需要变动的代码区别开来。抽象出来做为领域服务。

DDD 4层架构

  • 用户接口层
  • 应用层
  • 领域层
  • 基础层