又谈领域模型

       昨天,突然和阿敏谈起领域模型,发现自己的理解还是有些歧异于是看了坛子里robbin关于领域模型的一些探讨,又吧...老马的企业应用架构模式拿出来翻了翻好象又增加了些理解,领域模型大体分为三种(也可分为四种)分别为失血,贫血,充血/(胀血)(robbin语)下面我总结了几条关于领域模型几个形态的一些不成熟的总结:

一:失血模型,首先分为PO,DAO,SERVICE三大块,在这里PO就是领域层,但它只是个承载值的对象,除了属性并没有其他的方法所以在这里领域并没有起到它控制业务的作用,由于只有属性所以我们叫它失血,而DAO层只做和数据库的交互使得业务操作和数据库操作分离,其中Service层则作为一个操作的载体,其中有关于对象的所有操作,包括对象所要涉及到的集合类操作,并在这里做关于事务等的管理.

二:贫血模型:同样分为刚才失血模型的几层,但它和失血模型的区别在于领域层中,除了基本属性外还包含关系此对象的一些方法(这些方法不涉及数据库操作)例如一些临时对象的组成,或对对象中的值的分析等操作,Service则是做集合类的操作,以及对在DoMain层中所涉及到的对象的操作并对这些操作进行封装,以保证事务和结构的完整性.此模型可充分体现OO特点!(个人体会)

三:充血模型,层次也是Domain,DAO,Service三层,但在领域层中管理所有的代码包括集合和对象的操作,Service只当成一个接口并没有太多实际代码只是对Domain中代码的封装,在robbin的帖子中,貌似谈到需要在Domain中进行事务,但我认为为了保持事务完整的特点事务可能在Service控制相对更贴切些!

另外还有一种貌似是同仁们总结出的一种所谓的胀血模型,就是说把Service也喀嚓掉,只留DAO和Domain而Domain做所有的处理,虽然这不失为一种快速开发的手段,但个人感觉已经完全脱离OO的思想了,好象几种特性都没体现出来...如果项目的模块以及规模相对较大我想此模型应该不能胜任.

    以上是我自己的一些看法并不成熟也许本身说的就是错的,还需要继续看看老马的那本书,能够有个更深的体会.其实我认为各个项目自然有它自己的特点不应该循规蹈矩必须按照哪种模型,没有最好只有更好其实就是这样只有选择对的,才可能在项目中减少成本,时间开发量并对项目以后的维护起一个积极的引导作用!