充血模型在理论上非常优雅，但是在工程实践中不尽人意，贫血模型虽然表面上看简单粗暴，但是在工程实践中依旧有很多优异之处。
充血模型保持了领域模型的原貌，可以比较直接地映射程序的变更，代码修改起来比较直接。充血模型会保持了对象的封装性，使得领域模型在面临多态、继承等复杂结构时，易于变更。
1. 充血模型的优缺点
1.1 贫血模型比充血模型更加简单易行
充血模型的架构设计图.png
在领域建模时，每个订单具有多个订单明细，还要具有相关的用户信息与商品信息。
- 因此在装载一个订单时，需要同时查询出其订单明细与商品信息，用户信息，这些需要有强大的工厂进行装配，装载订单后，还需要放在仓库中进行缓存，需要订单仓库具有缓存能力。
- 在保存订单时，需要同时保存订单与订单明细，并将他们放在一个事务中。这些都需要强有力的事务支持。
贫血模型的架构设计图.png
贫血模型是直接调用service，service通过dao进行访问。在这个过程中Dao查询数据库中的某个表，直接将结果交给service进行处理使用。
1.2 充血模型需要更强的设计与组织能力
- 充血模型需要开发人员具有更强的OOA/D能力，分析业务，业务建模与设计能力。
在订单系统中，开发人员首先需要进行领域建模，分析清楚该场景中的订单、订单明细、用户、商品等领域对象的关联关系。还要分析各个领域对象在真实世界中都有什么行为，对应到软件中都有什么方法，在此基础上在进行软件开发。
- 充血模型需要有较强的团队协作能力
比如订单在创建时，需要对用户以及用户地址等信息进行查询。此时订单service不能直接去查询用户及用户地址的相关表，而是去调用用户service的接口相关接口，这时候开发订单的同学要让开发用户的同学提供相应的接口。
- 贫血模型所有业务处理过程都交给Service去完成
在实际开发过程中，需要什么功能就调用相应Dao，程序简单就会容易理解。
1.3 贫血模型更容易应对复杂的业务处理场景
采用贫血模型：将复杂的业务处理场景，划分成多个相对独立的步骤，然后将这些独立步骤分配给多个Service串联起来执行。
2. 什么时候要设计为充血对象
贫血模型和充血模型都各有优缺点，到底选择充血模型还是贫血模式要根据实际情况。
充血模型和贫血模型的差别就在于业务逻辑到底在哪里去实现：
- 需要将封装的业务逻辑放到领域对象中，则按照充血模型去设计；
- 除此之外的业务逻辑放到service（领域服务），按照贫血模型去设计；
需要作为充血模型设计的业务逻辑：
1. 【实际痛点解决方案】在领域模型中出现类似继承、多态的情况，则应该继承与多态的部分以充血对象的形式进行实现。
例如订单领域中有多种订单类型，（存在一些字段在不同的类型下被复用）。
- 若是贫血模型：
- 使用一个大DTO，就会势必在service中通过if...else来进行，就会造成代码腐化；
- 若是使用继承方式，每一种子类型都是一个DTO，需要路由到子service（策略服务）完成个性化处理；
- 若是充血模型：
- 若是使用继承方式，每一种子类型都是一个DO对象，DO对象内部实现个性化的逻辑。
2. 在软件设计过程中需要将一些类型或者编码进行转换。
例如一些boolean类型的字段，在数据库中实际上是没有boolean类型的，有些人习惯转换成0,1，有些人习惯转换成Y,N，这时候就会被使用的人一些疑惑，故可以封装在对象中。
3. 希望在软件设计中能更好地表现领域对象之间的关系。
4. “聚合”，在真实世界中那些代表整体与部分的事物。
网友评论