5分钟学JAVA-领域驱动设计DDD

总结

• 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层架构

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