openfans领域模型驱动的尝试

领域模型驱动( Domain Driven Design ),很热的名词。 Openfans ,不太热的网站。今天俺就借着很热的 ddd ,给不太热的 openfans 再造点势。 Openfans 就不多介绍了,网站用 spring+hibernate 为核心的一堆开源软件构建。有了 spring IOC hibernate ORM ,打着 ddd 的旗号也就名正言顺了很多。先声明其实俺对 ddd 的理解也多是道听途说,没有什么系统的学习过,倒是和 Joe 阿牛讨论过几次,颇有受益,他对这个理解还是很深刻的。

言归正传,就讲 openfans 现在经 ddd 思想改造过的模型。整体上看还是普通的三层架构体系:展现层、业务层、持久层。展现层用 spring mvc ,力图做到只是展示相关,避免出现业务逻辑。再具体细分,就是 jsp 页面只有展示逻辑,主要使用 jstl 完成显示功能。 Controller 负责从页面获得参数、把数据传回页面、控制页面流传和调用业务层的接口。持久层使用 hibernate ,在设计上我不是按 dao 方式为每个对象建立相应的 dao ,也不是 ddd 推荐的每个 domain 一个 repository ,而是分成了 Persistence Fetcher2 个接口。 Persistence 处理持久相关如 save remove 方法, Fetcher 则处理 get 相关。这样分的原因也很简单, persistence 是很稳固的,对象都可以共用一个接口如 save Object ),而 fetcher 就千变万化,需要分页、排序等接口。

这样设计是与业务层架构相关的。我采用的是 domain 对象(简称 DO + 一层薄薄 façade 的方式。 DO 处理自身的逻辑,包括持久功能。本身 DO 是没有持久能力的,需要依靠注入的 persistence 接口,这里就体现按 Persistence Fetcher 分开的一个好处, persistence 所有 DO 可以共用一个,给编程带来了方便。 Openfans 中采用的是 DO 继承一个抽象 PersistentObject 类的方式,这样 DO 方便的获得了注入的能力和持久的能力。这样做有何优缺点还需要做些讨论,为了方便我也就先这么用。 PersistentObject 代码如下:

public abstract class PersistentObject implements NeedPersist {

       private Persistence persistence;

 

       public void save() {

              persistence.save(this);

 

       }

 

       public void remove() {

              persistence.remove(this);

       }

 

       public void setPersistence(Persistence persistence) {

              this.persistence = persistence;

       }

 

       public Persistence getPersistence() {

              return persistence;

       }

}

这样 DO 只需要注入 persistence 就获得了持久的能力,而且可以把这种能力往下传递。 DO 获得了持久能力,就有点接近富血模型的想法了,他能够处理一些业务,做持久然后调用引用对象的业务和持久方法 ( 从另外的角度看持久与业务其实是分不开的 ) 。这样把业务封装在了领域本身,更适于用领域对象出发的方式去思考问题。领域层的 façade 主要是为了 Transaction 管理和隐藏 DO 接口。这样 DO 的业务方法都可以设置成 friendly ,仅相互间可见。 Façade 就放在 domain 包中,它负责给 DO 注入 persistence bean ,调用 DO 的接口,提供给 controller 一个 use case 级别的接口,同时它也代理 fetcher 的接口。

有了这个架构,实现起来也不复杂,要配置的 bean 很少(现在还没有使用 spring 2.0 DO 配置在容器中)。设计就从 DO 出发,明确它的属性和方法,让 hibernate 自己生成数据库表。

       这样设计也算是一次尝试吧,其中肯定有很多考虑不周的地方,需要不断的讨论和改进。

posted on 2006-05-22 18:28 pesome 阅读(1295) 评论(4)  编辑  收藏 所属分类: 系统架构

评论

# re: openfans领域模型驱动的尝试 2006-05-25 09:27 D.B

与我去年项目中对DomainModel的设计实现相似,
跟一般理解的DomainModel不同,这样的DomainObject是全功能的DomainObject(包括业务逻辑和持久化处理),
优点是Do的客户端可以比较省心(就像EntityBean,客户端不需要关心持久化),
缺点是DomainObject层依赖Dao层(这是大师们所反对的)。  回复  更多评论   

# re: openfans领域模型驱动的尝试 2006-05-25 13:50 pesom

呵呵,好容易找到个参与讨论的。理想状况是透明持久化,但由于设施还不完善,现在较难做到。用hibernate,如果do在session中,是不需对持久层产生依赖的,但不在session中的那些对象(如表单过来的对象)呢?do具备了能力,从封装、耦合和重用的角度看,还是很有益处的。欢迎大家多做讨论,可以到openfans上去讨论,呵呵!  回复  更多评论   

# re: openfans领域模型驱动的尝试 2007-02-02 18:22 pig345

与我去年项目中对DomainModel的设计实现相似,
跟一般理解的DomainModel不同,这样的DomainObject是全功能的DomainObject(包括业务逻辑和持久化处理),
优点是Do的客户端可以比较省心(就像EntityBean,客户端不需要关心持久化),
缺点是DomainObject层依赖Dao层(这是大师们所反对的)
-------------------------------------------------
深有同感,
一直没搞清楚 业界的大师们是如何在保持富血模型的同时--让DomainObject层与Dao层不相依赖的。
起码从现在的普遍应用的技术上看似乎是不可能的。  回复  更多评论   

# re: openfans领域模型驱动的尝试 2007-03-25 14:32 coolfish

现在看来domain object的所依赖的一些持久化的操作(DAO)的,需要借助AOP和spring 的注入来实现。  回复  更多评论   


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


网站导航:
 
<2006年5月>
30123456
78910111213
14151617181920
21222324252627
28293031123
45678910

导航

统计

公告

主要记录作者在学习java中的每一步足迹。除非特别说明,所有文章均为本blog作者原创,如需转载请注明出处和原作者,如用于商业目的,需跟作者本人联系。
欢迎大家访问:

常用链接

留言簿(16)

随笔分类

随笔档案

文章分类

文章档案

相册

收藏夹

java技术

人间百态

朋友们的blog

搜索

最新评论

阅读排行榜

评论排行榜