充血模型和贫血模型
Martin Fowler很早以前就写过一篇文章，题目叫”贫血模型”。文章里面批判贫血的领域模型是不够优雅、不够OO的，提倡使用充血的领域模型。在Java世界里这是一直争论的话题。到底什么是贫血什么是充血呢？
贫血模型
贫血模型：是指领域对象里只有get和set方法，或者包含少量的CRUD方法，所有的业务逻辑都不包含在内而是放在Business Logic层。
优点是系统的层次结构清楚，各层之间单向依赖，Client->(Business Facade)->Business Logic->Data Access(ADO.NET)。当然Business Logic是依赖Domain Object的。似乎现在流行的架构就是这样，当然层次还可以细分。
该模型的缺点是不够面向对象，领域对象只是作为保存状态或者传递状态使用，所以就说只有数据没有行为的对象不是真正的对象。在Business Logic里面处理所有的业务逻辑，在POEAA(企业应用架构模式)一书中被称为Transaction Script模式。
充血模型
充血模型： 层次结构和上面的差不多，不过大多业务逻辑和持久化放在Domain Object里面，Business Logic只是简单封装部分业务逻辑以及控制事务、权限等，这样层次结构就变成Client->（Business Facade)->Business Logic->Domain Object->Data Access。
优点是面向对象，Business Logic符合单一职责，不像在贫血模型里面那样包含所有的业务逻辑太过沉重。
缺 点是如何划分业务逻辑，什么样的逻辑应该放在Domain Object中，什么样的业务逻辑应该放在Business Logic中，这是很含糊的。即使划分好了业务逻辑，由于分散在Business Logic和Domain Object层中，不能更好的分模块开发。熟悉业务逻辑的开发人员需要渗透到Domain Logic中去，而在Domian Logic又包含了持久化，对于开发者来说这十分混乱。 其次，因为Business Logic要控制事务并且为上层提供一个统一的服务调用入口点，它就必须把在Domain Logic里实现的业务逻辑全部重新包装一遍，完全属于重复劳动。
如果技术能够支持充血模型，那当然是最完美的解决方案。不过现在 的.NET框架并没有ORM工具（不算上开源的NHibernate，Castle之类），没有ORM就没有透明的持久化支持，在Domain Object层会对Data Access层构成依赖，如果脱离了Data Access层，Domain Object的业务逻辑就无法进行单元测试，这也是很致命的。如果有像spring的动态注入和hibernate的透明持久化支持，那么充血模型还是能 够实现的。
领域模型
自从Martin Fowler的DDD（Domain Driven Develop 领域驱动开发）提出来之后，无数的人就开始非议ORM方式下的持久化实体类，抨击这种方式下的实体类是“贫血”的，缺乏丰富业务语义的。其实他们都犯了一个最基本的逻辑错误 － 偷换概念。
概念是如何被偷换的呢？请注意，领域模型（Domain Model）是一个商业建模范畴的概念，他和软件开发并无一丝一毫的关系，即使一个企业他不开发软件，他也具备他的业务模型，所有的同行业的企业他们的业务模型必定有非常大的共性和内在的规律性，由这个行业内的各个企业的业务模型再向上抽象出来整个行业的业务模型，这个东西即“领域模型”。一个掌握了行业领域模型的软件公司，根本不需要再给人家开发项目了，根本不需要靠软件开发养活自己了，你光给这个行业的企业提供业务咨询已经赚得非常丰厚的利润了。以我现在兼职所在的公司来说，就是这样一家软件公司，在行业内积累了足够的领域模型，成立了一个专门的咨询部门，这个部门下面都是咨询师，他们是不管软件开发的，也不懂软件开发，他们就专门教这个行业的客户，教他们怎么去做自己的业务，他们比客户还精通客户的业务，光是业务咨询已经可以为公司带来很多的收入。
而软件开发呢？一个并没有行业经验积累的软件公司，它开发的软件，基本上完全是需求驱动，而不是领域模型驱动。只有具备了领域模型积累的公司才有资格去谈领域模型驱动软件开发。在由领域模型往某种编程语言如Java上来实现的时候，绝对不会是1:1的对应关系，即使是粗颗粒度的EJB2模型都做不到，更不要说更加强调细颗粒度的POJO模型呢？用面向对象的语言如Java来编写一个领域模型，如果是用EJB2模型，你需要使用最少两个以上的EJB，即一个 Session Bean，处理面向流程的控制逻辑，一个Entity Bean，处理面向持久化的实体逻辑（持久化操作附着在Entity Bean的Home接口上）。如果是更加复杂的领域模型，那么你需要更多的EJB，也许是一个领域模型需要多个Entity Bean和多个Session Bean。现在我们使用基于POJO模型的实现，那么粗颗粒度的EJB还要继续细分：一个Entity Bean要剥离出来至少三个以上的POJO，即一个或者多个实体类，一个或者多个DAO接口类，一个或者多个DAO接口实现类；一个Session Bean要切分为多个业务Bean。
由此我们终于看出来概念是怎样被偷换的了，一个商业概念的抽象领域模型被一个Java持久化实体类替代了。但是我们应该看到，Martin批评的贫血的领域模型并不是Hibernate实体类，Martin指的贫血的领域模型实际上是缺乏丰富业务逻辑概念的领域抽象模型，这和Hibernate实体类完全是风牛马不相及的东西。而Hibernate实体类只是具体编码过程中，为了实现一个领域模型而编写的一组基于POJO的对象中的，完成领域模型某个特征的类。而这个领域模型完整的特征并不应该，也不可能由一个非常粗颗粒度的单类完成，而是由一组互相协作的类完成：即Hibernate的实体类保持领域模型的状态；DAO接口实现类完成领域模型的持久化操作；Spring Bean类完成领域模型的逻辑控制功能。
POJO指的就是非EJB那种重量级，高侵入性的组件模型，关于POJO的定义，你同样可以在Martin Fowler的bliki上面找到。
Spring的Bean是不是POJO？ 是的！
Hibernate的entity是不是POJO？是的！
DAO接口是不是POJO？是的！
EJB是不是POJO？ 不是的！
我没有看过Martin的DDD，我按照自己的理解， POJO domain models指的就是轻量级的领域模型。何为轻量级？ 把领域模型的各个特征，各个属性，各个逻辑都塞到一个class里面叫做轻量级吗？
我认为，Martin批评的贫血的领域模型是指只关注了领域模型持久化特征方面，而忽略了领域模型其他特征方面的模型，这样的模型是贫血的。因为这种模型只关注了模型在技术层面的外在表现，也就是说只关注了数据的存取操作，而忽视了模型蕴含的业务核心价值。
举例来说，我们编一个银行软件，如果你只关注了账户的增删改查，这叫做贫血！而实际上你应该关注的是账户的业务特征，而不是数据特征，你应该关注的是账号开立的业务，账户注销的业务，账号过户的业务等等，这才是领域模型。这种领域模型在一个单纯的技术实现层面来说，对于最简单的业务，你可能只是Account类的增删改查，但是对于复杂的业务来说，他就不单但是一个类，一个表的简单操作了，例如开立账户，你要收手续费，以及考察个人财务状况，那么此时你需要的就是一组协作的类。
Martin提到领域模型，意在强调我们应该关注软件的业务，关注行业知识的内在规律，并且把这种规律建模为领域模型，批评拿到一个软件，脑子里面光想到数据库增删改查的人。这和我们的Hibernate持久化类毫无关系！
我的看法是：一个抽象的领域模型具备多方面的特征，你需要用一组互相协作的类来完成它，每一个或者一组类承担这个领域模型的某个特征。例如某个领域模型，例如上面的账户，你需要一组Hibernate持久化类：包括Account类，User类，Finance类，一组SpringBean类，AccountManager，FinanceManager，一组DAO接口和实现类。由这些POJO的类互相协作来共同完成这个领域模型。如果你仅仅关注Account的增删改查，那就贫血了，而如果你关注了账户的业务规则，并且考虑一组互相协作的类去完成它，就不是贫血的。
