贫血模型和充血模型

前言

作为一个java软件开发人员，从开始学习java开始，都一直在说面向对象，但是在日常开发中，一般的开发人员在开发业务的过程中，往往并不是完全的面向对象的，特别是业务流程，有时候其实是面向过程的一种开发模式。
一般的流程式开发，都是按照流程一步步进行开发，针对接口进行按部就班的开发，并不是说这种方式完全不可取，而且对于正常的思维逻辑来说，这样的方式更加有利于代码的阅读和理解，特别是某个功能点，但是当业务模块越来越庞大，有些问题就会慢慢的暴露出来，比如在电商场景下，判断库存问题，一般的做法是抽出一个公共的方法供其他地方使用，但是往往多人开发的情况下，容易多个这样的方法，每个开发人员自己涉及的地方统一调用，这样就对后续的维护产生了很多影响。
面向对象的开发模式，会创建一个实体，在该实体内会有各种各样的接口，就比如库存判断，就可能放在商品实体内进行判断等等。
这里就引入了贫血模型和充血模型的概念。

贫血模型

贫血模型最早广泛应用是源自于EJB2，把“行为”（可以理解为逻辑、过程）和“状态”（可以理解为数据，即成员变量）分离到不同的对象中，只有状态的对象即为“贫血对象”（常被称为vo--value object）。
缺点：数据和操作的分离，导致了数据更加不可控，任何人都可以随意操作数据。缺乏可控性和安全性
优点：符合大多数开发人员的开发习惯。状态对象职责简单，在领域设计并不完善时，不会导致代码混乱。在业务简单的情况下，能够很快速的开发而且不会造成过度设计。

充血模型

充血模型，就是面向对象设计的本质：“一个对象是拥有状态和行为的”，比如说一个人自己就可以跑，可以跳，没有必要有一个manager去操作人去跑去跳。就是一个完整的对象。
缺点：设计上面存在难度，需要比较完备的思考去设计。某种程度上，在现有开发人员的思维来说比较难理解。在简单的业务下，这样的设计势必导致开发时间的延长，过度的设计导致本来简单的项目异常臃肿。
优点：面向对象的设计，使得数据更加安全，对象功能更加完备，后续维护成本降低。

后记

之后会针对DDD根据自己的理解进行讲述。