对领域模型实现的总结性观点

陶文发起的对领域模型的最新讨论：领域模型的价值与困境，在这个讨论当中，我的关注点是，在现在的技术水平下，我们如何把领域模型的理论和我们实际应用开发框架结合起来，总结出最佳实践：

第一、DAO层和TransactionScript层是邪恶的！

我们在2004年一直跨度到2007年讨论来讨论去，其实都有一个隐含的前提条件：你的领域模型终究无法脱离对DAO层的依赖，以及需要TransactionScript层的包裹。而这样一来，领域模型的通用性、可移植性、业务逻辑的表达能力基本全部丧失，沦为框架限制下的奴隶。

而我们看看现在Java领域的技术进步，JPA已经普及，EJB3的隐含事务管理，甚至连Spring也可以简化成@Transactional，现在已经是我们可以去掉DAO和TransactionScript的时代了。


第二、Seam在消除了DAO层和TransactionScript以后，领域模型的感觉已经呼之欲出

这个不用多说，大家自己去看Seam文档好了。我唯一想强调的是entity bean和business bean分开有没有必要性，我的看法是有必要！这还是和Java本身语言的限制有关系：

1、Java语法表达能力有限，entity bean又不得不弄一大堆getter/setter方法，都放在一个class里面，代码的可阅读性非常差

2、business bean的很多业务逻辑方法需要容器环境，不像Rails的model可以直接mixin进来

3、Java做为目前最主流的工业语言，开发团队都是大规模编码协作的，你都放在一个class里面，团队协作会遇到很大的麻烦(事实上RoR现在也有这样的问题，但是RoR开发效率高，往往不需要那么大规模的开发团队)

3、领域模型不同类别的业务逻辑可以很容易的分到几个不同的business bean里面，这样对团队协作的好处很大。


第三、不考虑框架限制，All-in-One的领域模型好不好？

比方说RoR的model就是All-in-One的，但是一旦出现可以抽象出来，比较通用的业务逻辑，我们还是会把这些逻辑抽出来，单独实现，然后再mixin回去。所以没有必要All-in-One，根据你的实际需要来决定放在一个class里面，还是拆开成几个class。

所以最终我对这个问题的总结就是：

一、只要技术框架能够实现，尽量使用领域模型

二、无论Java还是Ruby，必须消灭DAO和TransactionScript

三、领域模型不必All-in-One，Java可以分割为 1个entity bean和几个business bean，而Ruby可以分割为1个model和几个mixin的module。

评论

11 楼 xiaosi 2008-12-01  

说的很有道理

10 楼 dicom 2008-12-01  

1. Domain Model是用来描述业务领域内的对象及其之间的关系的，目前的Domain model能够

做到这个，那就不能称其“贫血”。Domain Model应该是纯粹的，业务逻辑和持久化不应该是

Domain Model里描述的，业务逻辑属于Business Process Model, 持久化则是系统功能。

Domain Model不应该依赖DAO，是DAO依赖领域模型，Business Service则依赖Domain Model和

DAO

2. 分层，是把复杂系统进行分解成多个可把握的简化模块，由于系统本身还需要重新组合，

所以分层本身是将复杂系统更复杂了（增加了模块间的组合的复杂性和分层体系结构本身技术

复杂性），但各个模块简化了，易于理解把握和工作。

3. 分层本身适合按模块分工，和当前大多数按功能分工不相符。按功能或特性分工协作，要

求每个人都把握整个体系结构，分层增加了复杂性，但按特性分工不易整合。

4. 分层结构易扩展，适于大型项目（到底多大所大型呢？）

5. 如果对分层的体系结构熟悉的话，开发效率并不低（虽然代码量较大，但不复杂，易于调

试、测试和实现），可能有点boring，但更易于合作分工。

9 楼 andycui 2008-12-01  

Dao要消灭的话，可以使用一个通用dao，而不要一个domain object一个dao，我们现在的项目就是，导致了太多的dao，或者干脆把dao的操作直接整合进domain object。

至于transaction的包裹，通过spring的话需要配置文件或者annotation，唉，其实我估计大家用的最多的就是spring的事务支持了，看看也就没啥了，以前的EJB早就提供了的功能，EJB3不也很好吗？ 另外spring的事务支持团队里自己实现也是非常容易的，大家不要为了spring而spring。

8 楼 netbaixc_gmail_com 2008-12-01  

robbin,大概看了那几个“血型”，嘿嘿，以前呆在国内一个知名公司里，平台是基于spring开发的，就要求分层，service里是描述事务和对外的门面，domain是针对业务的逻辑处理，dao是数据库操作，至于你说的domain object，是简单JAVA对象.当时的开发真是麻烦啊，尤其是要求不能跨层调用，就是command(响应http request)->service->domain->dao，而且这些都是通过spring的IOC配置在XML中，哇塞，那个配置文件看得人是头晕眼花，开发个CRUD那是一个痛苦啊，公司虽然提供了代码机来生成，可是也蛮麻烦的，让人忍不住想，这么搞有么价值？因为庞大的代码和配置文件，使得在开发和维护过程中需要阅读太多的东西了。虽然这些文件确实因为OO而变得职责单一，但是文件太多了，看起来也很费劲的！
说分层也好，说OO划分单一职责也好，不就是希望提高开发效率，利于后期维护么？但是如果分得太细，就会导致代码庞大；如果想要精简代码，有人说就得all-in-one。许多人在这个权衡上争辩，其实有一些更好的想法反而被埋没了，特此拍砖。
1.可以划分得越细越好，涨血到爆血，但是要伴随提供一个图形化的IDE，开发者使用IDE开发，将那么庞大的文件通过工具精简透明掉，开发人员在开发思路上仍然保持清晰的划分，但实际开发和维护通过图形化的向导啊之类的工具帮助来实现。现在很多中间件厂商都有提供哦。
2.采用元数据。记得有个技术公司的技术总监提点我：“小伙子，你看我们的项目，里面的代码不都是在描述业务么？什么校验，什么计算，什么查询”。其实可以将这些业务规则用纯数据来描述，按关系数据表来细粒度管理，然后通过一个框架式的代码来读取这些数据，进行“解析式”执行。这里的数据才是最精简的代码。

7 楼 icewubin 2008-12-01  

czx566 写道

程序员最终要被智能编程消灭到

汇编被C取代的时候，也没见程序员失业啊。

6 楼 china8jie 2008-12-01  

Why 消灭 Dao ??

那我们一直实践的东西是落后的? 噁待淘汰的 ?

5 楼 czx566 2008-12-01  

先消灭  DAO 

再消灭 View bean

最后程序员 只剩下 Business bean摆弄了
呵呵

程序员最终要被智能编程消灭到

4 楼 upheart 2008-12-01  

抽象，抽象，抽象，一层，两层到N层
简化，简化，简化，N层，两层到一层

3 楼 didasoft 2008-12-01  

didasoft 写道

Robin能够简单解释一下：领域模型All-in-one指的是什么概念？

无法修改评论？写错字了。

Robbin能否简单解释一下：领域模型All-in-one指的是什么概念？

2 楼 didasoft 2008-12-01  

Robin能够简单解释一下：领域模型All-in-one指的是什么概念？

1 楼 icewubin 2008-11-30  

引用

Java可以分割为 1个entity bean和几个business bean

只要是关系数据库，请问business bean放的难道不是TransactionScript么，还是我理解有问题？