DDD领域驱动模型笔记

1、传统MVC模式，service中处理对于业务，各个业务service做的事情都有很多相似部分，并且代码混乱，不容易理解，不便于修改
DDD模式，按照业务功能进行划分领域，使得业务service中的代码在后续业务变更时代码不需要进行改变，整个业务流程也明朗清晰
2、例如，抽象出来一个checkService借口，具体业务的check具体去实现checkService即可，业务service中永远只需要调用checkService的check方法即可，并且，后续的更新拓展也不需要修改业务代码，从而达到一个防腐层(防止代码腐化)的效果
3、mvc：商品实体类，用户实体类，用户买商品，写个service，包含，校验参数，查询库存，购买商品，调用三方接口，接口返回等等
DDD：商品域，用户域，用户和商品建立领域关系，比如，购买商品
参数校验在checkService域里面做
域和域之前不建立直接的关系
4、在基于充血模型的 DDD 开发模式中，Service 层包含 Service 类和 Domain 类两部分。Domain 就相当于贫血模型中的 BO。不过，Domain 与 BO 的区别在于它是基于充血模型开发的，既包含数据，也包含业务逻辑。而 Service 类变得非常单薄。

基于充血模型的 DDD 开发模式，跟基于贫血模型的传统开发模式的主要区别就在 Service 层，Controller 层和 Repository 层的代码基本上相同。

总结一下的话就是，基于贫血模型的传统的开发模式，重 Service 轻 BO；基于充血模型的 DDD 开发模式，轻 Service 重Domain。
5、贫血模型：使用贫血模型就会在service中new对象，set属性，然后调用service中的方法，实体类就更像是一种数据结构，而不像是一个对象，整个操作是面向过程而不是面向对对象

充血模型：使用充血模式在service中只需要调用domain对应的方法，不需要关心怎么创建对象，怎么set属性，甚至是咋么操作数据库，service中只有业务的流程步骤，这个操作满足面向对象的思想，充血模型是有血有肉的，核心领域方法都放到模型去去，而不是把领域方法放到模型之上的service层中去。

参考文档：https://www.ituring.com.cn/article/125