贫血模型架构的设计粒度问题

贫血模型与充血模型的讨论很多了，贫血模型是指建立的模型只有getset方法，只有属性没有行为,理想的领域模型是domain中包含大多数业务逻辑，service起到门面的作用，并且放置事务，如果采用贫血模型，现实中我们还是采用贫血模型也是能够解决问题的, 系统各层可能都会依赖domain model。

 

 

 

 

在这种架构下，我们写出的类、方法往往过大，往往是面

 

向过程思想。action --->service ----->dao，领域模型的构建与service的构建基本脱节，对于领域模型的行为，没

 

有清晰的位置约束，往往是一个大模块一个大service，导致这个模块的方法全部集中在这个service中，service的粒度

严重不合理，因此容易写出过于臃肿的service，service中的方法也往往过大。 

 

怎么解决呢？从业务模型或者领域模型入手，分析真正的领域模型，将真正的领域模型对应为我们的service。这个过

 

程是一个逐渐清晰逐渐分析的过程，也可能在系统分析初期，这些领域模型都没有建立起来，只是一些零散的业务概念，随

 

着系统分析的进行，领域模型逐渐清晰，进而转化为service。比如我们的网上购物系统，订单、顾客、商品是核心的业务

 

模型。

 

 

这里面临一个问题，就是什么是领域模型。首先区分建立的实体是DTO还是DOMAIN，不是有了getset方法的类就叫做领

 

域模型，不是为了向页面传输值在domain包下建立一个实体类，它是否有实际的业务含义，是否在系统的业务领域具有核

 

心的业务概念，一个页面展示的一条记录，肯定是有业务含义的，但是这个业务含义是否具有核心的业务概念是不一定的。

 

 

 

 

     DTO是用于展示数据的，而页面展示的数据不一定是领域模型的范畴。

 

    在报表型系统中，领域模型的概念很弱，报表展示的数据项，这些都是DTO，你说不出它是现实世界的什么名词，因此

 

这种查询实体一般不是domain而是DTO，我们甚至采用MAP向前台传值。这个时候我们的service怎么建立呢？？ 一个

小模块一个service，但是必须保证service没有过多方法，且其依赖的service越少越好，如果依赖超过2个以上的

 

service，那么我就会考虑，是否需要将service简化，提炼出另外的类。

 

     同样，domain中的某些数据也不一定需要展示并传向页面，某些时候，可以使用domain向页面传值。