贫血模型和充血模型
这两个概念是早些时候Martin Fowler总结出来的两种常见模型设计类型，没有说谁好谁不好，为不同的模型类别选择合适的场景是设计者的工作。没有工具本身的问题，只有工具使用者的问题。
?
?
贫血模型是指领域对象里只有get和set方法（POJO），所有的业务逻辑都不包含在内而是放在Business Logic层。
?
?
?
它的优点是面向对象，Business Logic符合单一职责，不像在贫血模型里面那样包含所有的业务逻辑太过沉重。
?
缺点是如何划分业务逻辑，什么样的逻辑应该放在Domain Object中，什么样的业务逻辑应该放在Business Logic中，这是很含糊的。即使划分好了业务逻辑，由于分散在Business Logic和Domain Object层中，不能更好的分模块开发。熟悉业务逻辑的开发人员需要渗透到Domain Logic中去，而在Domian Logic又包含了持久化，对于开发者来说这十分混乱。? 其次，如果Business Logic要控制事务并且为上层提供一个统一的服务调用入口点，它就必须把在Domain Logic里实现的业务逻辑全部重新包装一遍，完全属于重复劳动。
?
使用RoR开发时，?每一个领域模型对象都可以具备自己的基础业务方法，通常满足充血模型的特征。充血模型更加适合较复杂业务逻辑的设计开发。
?
充血模型的层次和模块的划分是一门学问，对开发人员要求亦较高，可以考虑定义这样的一些规则：
（1）事务控制不要放在领域模型的对象中实现，可以放在facade中完成。
（2）领域模型对象中只保留该模型驱动的一般方法，对于业务特征明显的特异场景方法调用放在facade中完成。
?
?
万事都不是绝对的，也有一些看起来不易解决的问题。例如，考虑到性能的需要，我需要一次查询出满足某种条件的用户和某种条件的产品，他们二者之间通过订购关系关联起来，可能发现这种情形下，上述的模型层次划分变得无解了……
?
