四种领域模型

<style type="text/css"> <!-- p {margin-bottom:0.08in} a:link {} --> </style>

我们在做领域设计阶段时,会自然而然的得到一些关键词,这其中可能就包括了我们需要领域模型的原形;依据此原形，我们创建领域模型,并在以后的详细设计中不段的调整和精化它;最终形成我们领域模型(Entity);

在初期,我们肯定给这些模型给予属性,set或get方法;在这之后,,我们会根据RDD的方式完善它,确定它的行为;但是这个行为的确定往往都没固定边界;要比较好确定这些行为,,往往难度比较大;;;

我这里要说的四种领域模型,这就必须提到ORM和DAO,我认为没有这两个前提,在这里说领域模型就没多大意思了;

首先说失血模型,简单理解是只有属性的实体对象,也就是数据对象;

贫血模型,是在上面模型的基础上增加了CRUD这四个基本功能,而业务逻辑是放到Service处理的.

失血和贫血的优点在于层次结构清楚，各层之间单向依赖，Client->(BusinessFacade)->Business Logic->Data Access(ADO.NET)。当然BusinessLogic是依赖DomainObject的。

缺点是它不OO,,不过我认为这到不是很重要,但网上也很多争论的地方也在这里

充血模型和贫血结构上差不多,不同的是它把大部分与自己相关领域的行为或者逻辑放到领域对象里面了,而业务层或者Service中只有少量的逻辑,简单日志,权限,事务等,这样层次结构就变成Client->（BusinessFacade)->Business Logic->Domain Object->Data Access。

其优点是它是OO的,缺点也很明显,怎样划分业务逻辑在各领域模型之间,会非常困难,其次是在Domain中的逻辑常常会在BusinessLogic再次封装,以便为Business的上层提供消费接口,,,这样的话，,也就出现重复劳动了

最后还有一种胀血模型

1、失血模型

2、贫血模型

Service(业务逻辑，事务封装)--> DAO ---> domain object

3、充血模型

Service(事务封装)---> domain object <---> DAO

4、胀血模型

domainobject(事务封装，业务逻辑)<---> DAO