浅析：领域模型、贫血模型和充血模型

一、领域模型

   领域模型是领域内的概念类或现实世界中对象的可视化表示，又称为概念模型或分析对象模型，它专注于分析问题领域本身，发掘重要的业务领域概念，并建立业务领域概念之间的关系。

   领域模型从业务角色内部的观点定义了业务用例。该模型为产生预期效果确定了业务人员以及他们处理和使用的对象（“业务类和对象”）之间应该具有的静态和动态关系。它注重业务中承担的角色及其当前职责。这些模型类的对象组合在一起可以执行所有的业务用例。

二、贫血模型

   贫血模型是指使用的领域对象中只有setter和getter方法（POJO），所有的业务逻辑都不包含在领域对象中而是放在业务逻辑层。

   贫血模型下组织领域逻辑通常使用事务脚本模式，让每个过程对应用户可能要做的一个动作，每个动作由一个过程来驱动。也就是说在设计业务逻辑接口的时候，每个方法对应着用户的一个操作，这种模式有以下几个优点： 
 （1）它是一个大多数开发者都能够理解的简单过程模型（适合国内的绝大多数开发者）。 
 （2）它能够与一个使用行数据入口或表数据入口的简单数据访问层很好的协作。 
 （3）事务边界的显而易见，一个事务开始于脚本的开始，终止于脚本的结束，很容易通过代理（或切面）实现声明式事务。 
         然而，事务脚本模式的缺点也是很多的，随着领域逻辑复杂性的增加，系统的复杂性将迅速增加，程序结构将变得极度混乱。

         贫血模型实施的最大难度在于如何梳理好Business Logic层内部的划分关系，由于该层会比较庞大，边界不易控制，内部的各个模块之间的依赖关系不易管理，可以考虑这样这样的实现思路：

 （1）铺设扁平的原子业务逻辑层，即简单的CRUD操作（含批量数据操作）；

 （2）特定业务清晰的逻辑通过Facade层来组装原子操作实现。

 （3）给业务逻辑层实施模块划分，保持模块之间的松耦合的关系。

三、充血模型

   充血模型将大多数业务逻辑和持久化放在领域对象中，业务逻辑只是完成对业务逻辑的封装、事务和权限等的处理。

   充血模型的优点是面向对象，Business Logic符合单一职责，不像在贫血模型里面那样包含所有的业务逻辑太过沉重。缺点是如何划分业务逻辑，什么样的逻辑应该放在Domain Object中，什么样的业务逻辑应该放在Business Logic中，这是很含糊的。

注：图片来源于网络，仅供参考。