java充血模型orm框架,关于领域驱动设计和贫血、失血、充血模型

大部分应用Spring框架的Java

Web应用都相当关注单一职责原则和关注分离原则，但是在此之上却诞生了一些不太好的反模式和设计原则，比如：

领域模型对象只是用来存储应用的数据。(领域模型使用了贫血模型这种反模式)

业务逻辑位于服务层中，管理域对象的数据。

在服务层中，应用的每个实体对应一个服务类。

这类设计原则的应用非常广泛，我现在所在的Java

Web项目就是使用这样的设计原则进行架构设计的，基本都是常见的三层或多层架构，他们大概是什么样的呢？

Web层(俗称展现层吧，Presentation

Layer)：接收用户输入，将数据传至服务层；

服务层(Service Layer，可以叫Business Logic

Layer)：事务边界，处理业务逻辑、权限管理与授权，并与存储层通信；

存储层(Data access

layer)：与数据库进行通信，对数据进行持久化。

但是发现什么没有？问题出在了服务层，他承受了太多的职责，像事务管理、业务逻辑、权限检查等等，这违反了单一职责原则和关注分离原则，并且产生了大量的依赖和循环依赖。当业务复杂度上升时，服务层所包含的代码将会非常庞大和复杂，直接导致了测试成本的上升。

我这里正好有个例子，在现在的项目中，负责处理保险业务单的核心类中，包含了4000多行代码，它与数据库中某一关键表相关联，引用(注入)了十几个DAO。在数十个各类方法中，可以处理保单、再保、理赔等等各种不同的业务，同时它还深度依赖于hibernate，不但使用了ORM方法处理数据，甚至还直接用了HQL来获取数据。因为有众多其他服务类与他进行循环引用，项目后期这个庞然大物已经没有人敢轻易改动了，因为谁也不知道他到底都能做什么，重构更是不可能的事。

说了些服务层的坏话，那应该怎么改进呢？

首先，我们需要将业务逻辑从服务层移动到领域模型中，这样的好处是，服务层可以只负责应用逻辑(如数据有效性验证、授权检查、开始结束事务等)，领域模型可以专门负责其相关的业务逻辑。还是以之前的保单系统来距离，架构设计时完全可以针对保单、再保、理赔等多个领域模型进行建模，相关的业务可以分别放到不同的领域模型中，一些很有可能重复的业务代码都会被集中到一处，从而降低了复制-粘贴的可能性。

其次，将服务类变得更小，使之只负责单一的职责。文章中有个例子，例如用户账户的CRUD和其他操作，就可以将其放到两个不同的服务类中，一个负责账户的CRUD操作，另外一个负责与用户账户相关的其他操作。

这样就能使服务类变得小巧、松散、可测试了，同时还能降低其他人理解与重用的成本。

接下来的问题就是，在实际的项目中，怎样实践这些设计原则呢？

这里有一篇《领域驱动设计和开发实践》非常值得一看，他所推崇的分层结构和上文所述类似，甚至提出了一些更细节的规则：

服务层需要包含应用逻辑、用户会话的管理，但不能包含领域逻辑、业务逻辑和数据访问逻辑；

领域层(领域对象)应该包含业务逻辑，可以处理与业务相关的会话状态.但作为商业应用的核心，应该具有良好的可移植性，不能对特定框架(如Struts、Hibernate、EJB等)产生依赖

说到这里，终于到了讨论的正题——贫血、失血和充血模型。什么是贫血失血充血模型呢？简单来说

失血模型：模型仅仅包含数据的定义和getter/setter方法，业务逻辑和应用逻辑都放到服务层中。这种类在java中叫POJO，在.NET中叫POCO。

贫血模型：贫血模型中包含了一些业务逻辑，但不包含依赖持久层的业务逻辑。这部分依赖于持久层的业务逻辑将会放到服务层中。可以看出，贫血模型中的领域对象是不依赖于持久层的。

充血模型：充血模型中包含了所有的业务逻辑，包括依赖于持久层的业务逻辑。所以，使用充血模型的领域层是依赖于持久层，简单表示就是

UI层->服务层->领域层持久层

胀血模型：胀血模型就是把和业务逻辑不想关的其他应用逻辑(如授权、事务等)都放到领域模型中。我感觉胀血模型反而是另外一种的失血模型，因为服务层消失了，领域层干了服务层的事，到头来还是什么都没变。