闲谈Domain Model & Transaction Script

Domain Model对于大多数的人来说都不怎么的陌生,Domain Model作为实现业务层的两种重要方法之一,在PoEAA(企业应用架构模式)中得到Martin Fowler的大力推广,但个人觉得在Domain Model上的应用并不是那么的理想,这个还得从业务层实现的两种模式谈起,分别为Domain Model和Transaction Script,Domain Model的原则为采用Domain Object的方式来实现业务逻辑,使得业务逻辑得以聚合到对象本身,从本质上提升业务对象的可复用性,其优点就在于提升了业务对象的复用性和代码的整洁性,缺点则在于实现的难度较高,有一定的学习曲线;Transaction Script则为采用Script的方式编排业务逻辑,其优点在于实现起来简单,缺点在于代码中出现较多重复的业务逻辑块,在业务逻辑一旦变动时需要修改很多地方,降低了业务逻辑的复用性。
其实个人看法是Domain Model为采用OO构成业务层模型的思想,而Transaction Script为采用面向过程构成业务层模型的思想。
从需求分析开始谈起,在对需求进行OOA后,产生出系统的业务模型,通过OOD得到业务模型技术体系,那么在Domain Model很简单的就是将此业务模型技术体系进行Plain Object的实现,从此得到Domain Object,按照这样的逻辑Transaction Script其实是不应该会出现的,Transaction Script的产生当然是有它的原因的,在复杂的业务场景中需要通过多个Domain Object共同来完成业务功能的实现,而此时在设计不够良好的Domain Object模型的情况下很难通过Domain Object的协作来做到实现,需要在Domain Object的协作之外处理一些业务逻辑,这个时候Transaction Script就得以出现了,以Script的方式来协作Domain Object并同时补充其中的业务逻辑来完成业务功能的实现,其实这个时候已经可以看到,实现的方式确实是变简单了,但业务模型则被逐渐的拆离,在Domain Model中则强调Domain Object本身业务逻辑的实现,而业务层则通过引入一层薄Service作为对外的接口来提供业务场景的实现,此时的Service需要做的是调用Domain Object来完成业务场景的实现。
Domain Object对应到业务模型,在结合了持久层来完成相应业务Object的持久,个人觉得ORM的引入在这部分使得Domain Object在需要完成持久的时候更加的优秀,Domain Object中通过注释标识出需要持久的属性,当然这是因为ORM工具需要通过这些映射来处理,这样在对Domain Object作持久操作时可直接的进行,这样的Domain Object就构成了系统的核心部分,业务模型构成系统的核心模型,这是需求符合体现的关键。
至于View Object则由于其简单性很多时候必须构建,以保持View Layer的单一性以及只是View的性质。

posted on 2005-10-15 15:16 BlueDavy 阅读(3204) 评论(0)  编辑  收藏 所属分类: 系统设计


只有注册用户登录后才能发表评论。


网站导航:
 

公告

 









feedsky
抓虾
google reader
鲜果

导航

<2005年10月>
2526272829301
2345678
9101112131415
16171819202122
23242526272829
303112345

统计

随笔分类

随笔档案

文章档案

Blogger's

搜索

最新评论

阅读排行榜

评论排行榜