关于领域建模的实现

关于领域建模的实现

[url]http://gigix.blogdriver.com/gigix/166013.html [/url]


我们现在的做法是Transaction Script模式（http://www.martinfowler.com/eaaCatalog/transactionScript.html）。实体（也就是需要持久化的对象，有时我们也说它们就是领域对象）只是原始数据的对象形式，或者加上一些最简单的操作（只涉及本身数据的简单处理）。DAO负责将数据转化为实体对象，我们通常用Hibernate来实现。业务逻辑放在service里，每个service方法是一个Transaction Script。AppFuse（http://https://appfuse.dev.java.net/）也是按这种方式架构的。

Martin Fowler更倾向于Domain Model模式（http://www.martinfowler.com/eaaCatalog/domainModel.html）。领域对象不仅是原始数据的对象形式封装，而且包含几乎所有重要的业务逻辑。领域对象可以直接访问数据库，因此DAO不是必要的，而是通过一个他称为“mapper”的东西提供O/R映射。由于领域对象封装了业务逻辑，service只是一个很薄的facade，提供面向服务的接口。Spring的JPetstore范例就是按照这种方式架构的。但是，JPetstore的业务逻辑相当简单，我草草看了一下，似乎领域对象没有直接操作持久化逻辑，因此这并不是一个很有说服力的例子。或许更有说服力的是Pluto（http://jakarta.apache.org/pluto/）。在Pluto这里，需要持久化的大多是些配置信息（包括portal本身的配置、portlet的配置和用户配置），它并没有使用DAO，而是直接通过XML binding持久化到XML文件。

我不知道应该如何选择这两个体系结构模式。我不知道Transaction Script模式的缺点在哪里。我不知道Domain Model模式用起来会有什么困难。我不知道Martin Fowler为什么如此激烈地批评“贫血的领域对象”。这让我感到困惑和苦恼。我要首先再看一遍PoEAA的相关章节，再想想，再问问。我不喜欢感觉自己像个白痴。


http://gigix.blogdriver.com/gigix/168486.html

下午Jacques Lebrun帮忙找到了Domain Driven Design，还没来得及看。Martin Fowler说应该由Domain Model负责访问持久化逻辑，并借助Data Mapper封装持久化的实现细节。但是，我竟然找不到这样的一个例子。Spring JPetstore细看之下原来也是Transaction Script，只不过service的方法都非常非常简单，前天乍一看还以为和我们做的Transaction Script有什么不同呢。
看JPetstore唯一的收获是：不要使用DTO，用轻量级持久化框架（例如Hibernate或者iBatis），直接把实体对象到处传。

Domain Model模式看了仍然是半懂不懂，很多细节上的问题想不清楚。比如说，领域对象（或者说，实体）的创建和查找（对应于DAO的create方法和load方法）由谁来调用？仍然在service里调用吗？如果要放到实体类，在创建/查找操作之前，没有一个具体的实体对象存在的，那么就只能放在一个static方法里了，这是一个好的做法吗？

到哪里可以找到一个Domain Model体系结构的例子？我想看看究竟应该怎样去做。如果到明天晚上还没有进展，我就写信去问Martin Fowler本人。



http://gigix.blogdriver.com/gigix/168634.html

Potian几句话说得我好象有点开窍了。

原来，采用什么体系结构模式取决于我的实体（领域对象）干什么、我要持久化什么。如果像Pluto、OSUser，领域对象本身有复杂的功能，持久化的是一个功能组件的状态，Domain Model就比较合适。而我们做的很多web应用，实体代表的是简单的数据（比如“用户”，甚至是某种公文），业务操作大多是对领域对象的CRUD操作，Transaction Script就挺合理。我感觉桌面应用和这种web应用好象有点区别，原来就是这个区别：它们的业务操作是做了不同的事。

刚才对G-Roller做了一点修改，取消了DTO（http://www.aspectoriented.org:9080//space/2004-04-22#DTO?_我需要吗？），直接把实体传到表现层，感觉除了让程序变简单之外，并没有什么影响。不过有一点：接口上好象不那么漂亮。比如说，User有个getPosts()方法，但User和Post的关联是lazy的，如果直接在表现层调用User.getPosts()方法，就有可能来一个LazyInitializationException。当然，表现层本来就不应该这样获得Post对象，但这个接口是不是会给使用者造成困惑呢？好象又有点不开窍了。


http://gigix.blogdriver.com/gigix/169972.html

一个体系结构重构模式- -

名称：
用Domain Model替代Transaction Script

意图：
你的业务层采用Transaction Script模式实现
你希望将实现方式改为Domain Model模式

Bad Smells：
Long Method / Large Class——由于放置Transaction Script的service组件涉及全部业务逻辑的实现细节，其方法很容易变得冗长；如果对其使用Extract Method重构，则会使service实现类变得庞大。
Duplicate Code——不容易从现有的Transaction Script中找出可复用的代码，因此常常重复实现类似的逻辑。
Switch Statements——在领域对象有继承关系时，Transaction Script需要对不同类型的领域对象做不同的操作，此时容易造成基于类型的switch语句。
Data Class——领域对象只携带了数据，作为对象的职责不够。

重构过程：
使用Extract Method，消除Transaction Script中的重复代码。
使用Move Method，将领域对象固有的业务逻辑移到领域对象类中。
如果该方法需要使用DAO，则将DAO作为参数传入。
如果该方法需要使用其他service，说明该方法并不适合存在于特定领域对象类，而应该仍然存在于service组件中。
如果领域对象是一个继承体系，将业务逻辑移到其基类中。
如果第2步搬移的方法中有switch语句，使用Replace Conditional with Polymorphism消除之，将业务逻辑分配到领域对象的各个子类。

评论

1 楼 rustlingwind 2008-10-23  

好文好文，ding~~