openfans领域模型驱动的尝试

核心提示：领域模型驱动（ Domain Driven Design ），很热的名词，openfans领域模型驱动的尝试， Openfans ，不太热的网站，这样 DO 方便的获得了注入的能力和持久的能力，这样做有何优缺点还需要做些讨论， Openfans 就不多介绍了，网站用 sPRing+hibernate 为核心的一堆开源软

领域模型驱动（ Domain Driven Design ），很热的名词。 Openfans ，不太热的网站。 Openfans 就不多介绍了，网站用 sPRing+hibernate 为核心的一堆开源软件构建。有了 spring 的 IOC 和 hibernate 的 ORM ，打着 ddd 的旗号也就名正言顺了很多。

言归正传，就讲 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);