架构设计的"贫血模型"与"充血模型" 原

    以前就听别人说过这俩种模型。它们描述的对象是面向对象设计中的实体，构建领域模型(Domain model)时，贫血模型与充血模型给出了俩种不同的方案：

贫血模型：是指领域对象里只有get和set方法，或者包含少量的其它方法，与之有关的业务逻辑都不放在该类中，而是放在其它地方，比如Business logic层。

充血模型：充血模型与之不同，不仅有get/set方法，还有业务逻辑也在领域模型(Domain model)里面，Business Logic只是简单封装部分业务逻辑以及控制流程。

贫血模型的好处：

    每个贫血对象职责单一(体现在哪：每个对象几乎只有属性，get/set方法，无业务逻辑)，这样模块间、对象间解耦程度很高。

贫血模型的坏处：

    对象状态和行为分离(贫血模型中，对象只有属性，get/set方法，业务逻辑在不在对象类内部)，所以一个完整的业务逻辑描述不能在一个类中完成，而是一组相互协作的类共同完成的。可复用的颗粒度比较小，代码量膨胀很厉害，很重要的一点是业务逻辑的描述能力较差，一个稍微复杂的业务逻辑，就需要太多类和太多代码去表达。由于我公司项目里使用的就是这种模型，所以对此很有感触。

    该模型的缺点是不够面向对象，领域对象只是保存转态或者传递状态使用(想象一下项目里面从web层传到service层，再传到dao层)，只有数据没有行为的对象不是真正的对象。

充血模型的好处：

    对象自治度很高，表达能力强，适合于复杂的企业业务逻辑实现，可复用程度高。

充血模型的坏处：

    对象自治度高的结果就是不利于大规模团队分工协作。    

参考：

https://www.cnblogs.com/longshiyVip/p/5205451.html

盒马资深技术专家辉子：领域驱动设计、实践经验：https://www.jianshu.com/p/981cd8b5e3b1

(adsbygoogle = window.adsbygoogle || []).push({});