充血模型在理论结构上很优雅，然而在工程实践上却不尽人意。
而贫血模型从表面上看虽然简单粗暴，但在实践中却有很多优点。
简单总结以下几点优缺点对比
- 贫血模型比充血模型更加简单易行
充血模型将领域模型的原貌直接映射成了程序设计，因此在程序设计时需要增加更多的，诸如仓库，工厂的组件，对设计能力与架构提出了更高的要求。
充血模型架构设计图
比如订单系统设计，在领域建模时，每个订单有多个订单明细，还要对应相关的客户信息，商品信息，因此，在装在一个订单时，需要同时查出订单明细，客户信息，商品信息，这些都需要有强大的订单工厂进行装配，装载订单之后还需要在仓库中缓存，需要订单仓库需要缓存能力，此外在保存订单时还需要同时保存订单与订单明细，并且在同一个事物中，所有这些都需要强大的技术平台支持。
相反的，贫血模型则更加接地气，mvc层直接调用service，service通过dao进行数据访问，这个过程中每个dao都只查询数据库中的某个表，直接交给service使用，如：订单dao查询订单，订单明细dao查询订单明细，他们查询后不需要装配，而是直接交给订单service使用，在保存订单时，订单dao负责保存订单，明细dao负责保存明细，他们都是通过订单service负责组织，并且建立事物。贫血模型不需要仓库，工厂，缓存。一切都很简单粗暴，却又一目了然。
- 充血模型需要更强的设计与协作能力，技术实现对开发人员有更高的能力要求，需要有更强的OOA/D能力，分析业务，业务建模与设计能力。
比如在订单系统这个案例中，开发人员要先进行领域建模，分析清楚该场景中的订单、订单明细、用户、商品等领域对象的关联关系，还要分析各个领域对象在真实世界中都有什么行为对应到软件设计中都有什么方法在此基础上再进行设计开发。同时，充血模型需要有较强的团队协作能力。
比如在该场景中，当订单在进行创建时，需要对用户以及用户地址的相关信息进行查询。此时订单service 不能直接去查询用户和用户地址的相关表，而是去调用用户service 的相关接口。由用户service 去完成对用户相关表的查询。这时候开发订单模块的团队需要向开发用户模块的团队提出接口需求。与充血模型相比，贫血模型就比较简单于直接，所有业务处理过程都交给service 去完成。在业务处理过程中需要哪些表的数据就去调用相应的dao， 需要订单就找订单dao， 需要用户就找用户dao， 需要商品就找商品dao。 程序简单就易于理解，日后维护起来也比较容易。
总之，充血模型有种学院派气息，一切走流程，按规矩来；贫血模型则简单而直接。
- 贫血模型更容易应对复杂的业务处理场景。充血模型在进行设计时，是将所有的业务处理过程在领域对象的相应方法中去实现的。这样的设计，如果业务处理过程比较简单，还可以从容应对。但如果是面对非常复杂的业务处理场景时，就有一些力不从心。
在这些复杂的业务处理场景中，如果采用贫血模型，可以将复杂的业务处理场景划分成多个相对独立的步骤。然后将这些独立的步骤分配给多个service 串联起来执行。这样各个步骤就是以一种松耦合的形式串联的组织在一起，以领域对象作为参数，在各个service 中进行传递。在这样的设计中，领域，对象既可以做各个方法调用的输入，又可以作为他们的输出。
image.png
比如在上图的案例中，领域对象作为参数，首先调用service a 调用完以后将结果数据写入领域对象的前五个字段传递给service b，service b 拿到领域对象以后，既可以作为输入去读取前五个字段，又可以作为输出，将执行结果写入中间五个字段。最后将领域对象传递给service b 执行完操作以后去写后面五个字段。当所有字段都写入完成以后，存入数据库，完成所有操作。在这个过程中，如果日后需要变更，要增加一个处理过程，或者去掉一个处理过程，再或者调整他们的执行顺序都是比较容易的。这样的设计，要求处理过程必须在领域对象之外，在service 中实现。
如果采用充血模型的设计，就必须要将所有的处理过程都写入这个领域对象中去实现。无论这些处理过程有多复杂，这样的设计势必会加大日后变更维护的成本。
网友评论