充血模式和贫血模式
贫血模型：是指领域对象里只有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层中，不能更好的分模块开发。熟悉业务逻辑的开发人员需要shen透到Domain Logic中去，而在Domian Logic又包含了持久化，对于开发者来说这十分混乱。 其次，因为Business Logic要控制事务并且为上层提供一个统一的服务调用入口点，它就必须把在Domain Logic里实现的业务逻辑全部重新包装一遍，完全属于重复劳动。
如果技术能够支持充血模型，那当然是最完美的解决方案。不过现在的.NET框架并没有ORM工具（不算上开源的NHibernate，Castle之类），没有ORM就没有透明的持久化支持，在Domain Object层会对Data Access层构成依赖，如果脱离了Data Access层，Domain Object的业务逻辑就无法进行单元测试，这也是很致命的。如果有像Spring的动态注入和Hibernate的透明持久化支持，那么充血模型还是能够实现的。
选择了.NET平台开发，就是选择了开发高效、功能强大应用简单，最适合的模型就是贫血模型，或表数据入口，既有编译器和语言平台很好的支持，也符合微软提倡的开发模式。如果跟潮流在项目中使用充血模型，现有的ORM工具都很复杂难用，光是维护大量的映射文件都成问题。说贫血不够OO，它的Domain Object不够丰富，能把项目做好了，有一定的扩展能力和伸缩行就行了，也不一定要讲究优雅的面向对象。正如SOA，讲究松耦合、高内聚，服务端给客户端提供的服务，也就是一系列的方法调用加上DTO而已，不管服务的内部是不是面向对象的实现，至少它暴露出来的是过程式的服务。
什么是四色建模法
我的个人理解是
通过还原业务逻辑事件，依据是否影响公司的运营和发展，确定凭证作为时标型对象，并补全相关描述的建模方法。
四色建模法包括
时标型（Moment-Interval）对象：具有可追溯性的记录运营或管理数据的时刻或时段对象，用粉红色表示
PPT（Party/Place/Thing）对象：代表参与到流程中的参与方/地点/物，用绿色表示
角色（Role）对象：在时标型对象与 PPT 对象（通常是参与方）之间参与的角色，用黄色表示
描述（Description）对象：对 PPT 对象的一种补充描述，用蓝色表示
核心：时标型对象
时标型对象的特点
可追溯性的记录数据
代表某个时间的事实
如果缺失会影响企业的运营和管理
分析步骤
找到溯源事件
确定时标型对象
找到周围的PPT对象
找到角色
补全描述对象
一个完整的四色建模法完成品为下图所示
我们就得到了应用四色建模方法（color modeling）建立的一套领域模型。
简要回顾一下上面的过程，不难发现我们建模的次序和重点：
1.首先以满足管理和运营的需要为前提，寻找需要追溯的事件。
2.根据这些需要追溯，寻找足迹以及相应的时标性对象。
3.寻找时标性对象周围的人、事、物。
4.从中抽象角色。
5.把一些信息用描述对象补足。