领域模型（失血，贫血，充血，胀血）

一  mvc架构

先看看MVC三层架构和鲁棒图3元素对应关系。

 应用逻辑：如数据有效性验证、授权检查、开始结束事务等。业务逻辑：领域模型

• 服务层需要包含应用逻辑、用户会话的管理，但不能包含领域逻辑、业务逻辑和数据访问逻辑；
• 领域层（领域对象）应该包含业务逻辑，可以处理与业务相关的会话状态.但作为商业应用的核心，应该具有良好的可移植性，不能对特定框架（如Struts、Hibernate、EJB等）产生依赖

二  领域模型

领域模型分为4大类：失血模型、贫血模型、充血模型、胀血模型。想要理解这几个分类，先要知道“血”指的是domain object的model层内容。

1、失血模型

action

service  肿胀的服务逻辑

model：只包含get set方法

dao ：数据持久化

业务逻辑和应用逻辑都放到服务层中。这种类在java中叫POJO，在.NET中叫POCO

2、贫血模型

action

service ：组合服务 也叫事务服务

model：除包含get set方法，还包含 单服务 又叫原子服务

dao：数据持久化

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

3、充血模型

action

service ：组合服务 也叫事务服务

model：get set方法， 单服务 又叫原子服务，含数据持久化的逻辑

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

4、胀血模型

action

model：get set方法， 单服务又叫原子服务 ，数据持久化的逻辑 还包含组合服务，又叫事务服务

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

一般来说失血模型和胀血模型不常见，贫血模型和充血模型的差别在于，领域模型是否要依赖持久层，贫血模型是不依赖的，而充血模型是依赖的。至于是采用贫血模型还是充血模型，双方争论的焦点是领域模型是否要依赖持久层，因为依赖持久层就意味着单元测试的展开要更加困难（无法脱离框架进行测试，原文的讨论中这里专指Hibernate），领域层就更难独立，将来也更难从应用程序中剥离出来，当然好处是业务逻辑不必混放在不同的层中，使得单一职责性体现的更好。而支持者（充血模型）认为，只要将持久层抽象出来，即可减少测试的困难性，同时适用充血模型毕竟带来了不少开发上的便利性，除了依赖持久层这一点，拥有更多好处的充血模型仍然值得选择。最后，谁也没能说服谁，关于贫血模型和充血模型的选择，更多的要靠具体的业务场景来决定，并不能说哪一种更比哪一种好。设计模式这种东西不是向来都没有什么定论么。

我个人则倾向使用充血模型，因为充血模型更加像一个设计完善的系统架构，好在计算机世界里有很多的IOC和DI框架，唯一的缺陷依赖持久层可以通过各种变通的方法绕过，随着技术的进步，一些缺陷也会被慢慢解决。我的思路是这样的：先将持久层抽象为接口，然后通过服务层将持久层注入到领域模型中，这样领域模型仅仅会依赖于持久层的接口。而这个接口，可以利用现有框架的技术进行抽象。