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

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

第一、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。

评论

31 楼 flyzht 2012-04-11  

是否用领域模型和具体技术无关，领域模型就是POJO，就是没有任何技术，只用JDBC和JSP一样用领域模型

30 楼 flyzht 2012-04-11  

29 楼 sunshineparasol 2010-12-06  

肉饼真是大神!!

28 楼 pig345 2009-12-14  

http://pig345.iteye.com/blog/79822

27 楼 zorwi 2009-07-11  

netbaixc_gmail_com 写道

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.采用元数据。记得有个技术公司的技术总监提点我：“小伙子，你看我们的项目，里面的代码不都是在描述业务么？什么校验，什么计算，什么查询”。其实可以将这些业务规则用纯数据来描述，按关系数据表来细粒度管理，然后通过一个框架式的代码来读取这些数据，进行“解析式”执行。这里的数据才是最精简的代码。

= =||莫非是楼上？？？

26 楼 sslaowan 2009-03-05  

引用

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

     使用accessor跟Java语法表达能力有什么关系呢？包含accessor的作用很多，将对于属性变为private，可以通过是否创建accessor来觉得其读写性；包含验证代码；一些Domain Logic。当然嫌麻烦，或者本来所有的属性就都是可以读写的，并且不包含任何业务逻辑，未来也肯定不会包含，那就把属性的可见性改为public也OK了

引用

事实上RoR现在也有这样的问题，但是RoR开发效率高，往往不需要那么大规模的开发团队

开发效率高和团队规模之间有必然联系吗？业务巨复杂的ERP，从语言层面上讲，差别已经不大了，特别是将Spring+Hibernate Mix好之后，基本上只需要写业务逻辑就OK了。但就是那巨烦人巨多的业务逻辑，你就是用自然语言写都得写好几天。

引用

Spring也可以简化成@Transactional

这和你去掉DAO又有什么关系？
如果你的程序中到处都是一个业务方法中挤满了dao1.get(1); dao2.save(0)，那只能说dao被滥用，或者是设计太糟糕了，这并不是dao的错误。

dao和depository是一个东西，dao模式被人广为知道可能是因为J2EE模式，而depository是因为DDD，于是dao从领域建模角度是有现实对照物的，而非一个纯虚构。
另外，dao可以屏蔽掉数据持久化的实现，我们经常会遇到Hibernate出现瓶颈，改为jdbc+sql实现，改为jdbc+存储过程实现，我现在在改一个东西是将数据库持久化改为xml持久化。
这种分离是非常必要的：
1 技术需要（数据库替换，持久化框架更换，技术变迁，持久介质变化）
2 性能检测。可以非常容易的找到性能瓶颈，起码你可以单独去测数据访问代码和Java程序到底谁是瓶颈
3 异常转换。在DAO层统一异常类型，就像Spring做的那样
4 业务需要。持久化图书，到底应该是book.add，还是把book放进book depository（用Google金山词霸查到的书库一词）呢？bookDepository.add(book)。只不过在J2EE模式中叫成dao了，就成了bookDao.save(book)。因此按照领域建模，dao也是其中的一部分，然后在它里面，包含了内存到持久化设备转换的代码（比如保存到数据库里，保存到本地文件，上传到远程服务器，刻录到DVD，导成磁带）

25 楼 sundoctor 2009-01-04  

看了大家说了这么到， 我也说两够，我是不赞成一味追求分层的，我更喜欢No DAO,No Interface方式开发。

24 楼 chaotienhisang 2008-12-22  

不要将问题单纯化、该不该消亡和存在都是现实需求牵引的、技术只是服务的是放在二位考虑的

23 楼 llade 2008-12-06  

robbin 写道

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

DAO层为什么是邪恶的，假如DAO仅仅是CRUD加上基础查询功能，那么它是“整齐”的，可“归类”的,看不出有什么邪恶的地方。

如果设计得好的话，唯一和领域模型相交的可能就是那些findByXXX方法了(findById不算，因为每个entity都应该有个ID，是通用的)。但换个设计，假设XXX没有组合式业务语义（例如：PersonInSellDivision销售部员工，由销售部和员工两个语义实体组成），仅仅是property名，
那这些findByXXX方法也算是“整齐”的（findByName等）。这里唯一要确定的是你的一个DAO对应一个entity，避免“污染”。

剩下的组合条件怎么办？如果你是基于Hibernate的就用DetachedCriteria吧。如果你想抽象一层，就用你自己的Condiction类，再根据系统生成DetachedCriteria还是HQL还是SQL。那你的DAO就变为针对单个实体的CRUDF了，F除了基本的Property查找就是组合条件查找了。

那JOIN查找怎么办？entity之间的关系应该是在数据库建模的时候就应该确定，那它就能映射到ORM上。如果用Hibernate的话用DetachedCriteria
就可以很好的完成了（只是觉得奇怪，为什么没人发觉DetachedCriteria的价值？）.
如果一个DAO针对一个entity是“干净”的，那它远称不上邪恶。

至此，一个整齐干净的DAO，那一个entity转换一个DAO的对于一个精通JAVA的人来说根本不是问题，甚至不用人手，写个工具就可以完成。

把DAO整干净的行为我不知道算不算是COC？呵呵

TransactionScript应该抽象到容器上去，spring也是沿用了ejb的做法的，只是更易于配置。个人认为这也是Spring2.0之后不予余力地引入AspectJ切面描述的原因。对于AOP和OOP相辅相成的世界。既然TransactionScript那么邪恶，那就由AOP这把利刃管着吧。

robbin 写道

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

这个不用多说，大家自己去看Seam文档好了。

说说Seam，我的感觉是一个给annotation严重污染的，极度分散的框架。它不是消灭了DAO而是把DAO切成小块，装自己身上去了，一个弗兰肯斯坦。。。。em.createQuery("select msg from Message msg order by msg.datetime desc")。我看不出DAO给消灭痕迹。

说是依赖注入，我看是依赖查找，@PersistenceContext,@Logger，@XXX。原来查找的代码放到annotation上了。缩短了写法，本质一样。假如我用几个数据库几个PersistenceContext,是不是要区分@PersistenceContext(contextName=xxxx),contextName是我硬造的。

依赖注入只是手段，只是注入过程由一个容器的配置式去管理，配置式可以是XML和annotation，但从集中管理配置这个角度上看，annotation天生就不是集中管理的料，所以我说“极度分散”。只有配置被管理起来，而不是程序员自己分散地写着annotation(不妨设想一下一个被误用的annotation，你要找多少个Java文件来修改，annotation那么多，被误用的机会多着呢),才能称得上是依赖注入,否则都是“伪依赖注入”。

在这方面，我还看不到能替代XML的方案，唯一需要注意的是XML可以自定义任何标签，所以XML配置必须归纳为很少的几个标签，这样才不会让写配置的人精神高度紧张。反正我的脑袋不是赖昌星的脑袋，记不住几个电话号码，也记不住几个标签。

用annotation来实现那些script的灵活的功能.我只想强调的是,script是集中管理逻辑过程的描述语言，和annotation天生的分散特性是相悖的。

annotation超过10个，那它就是一门手艺，超过20个，那它就是一幅20个环的镣铐了。个人以为annotation只有用到基类和父类上才能真正显示它的威力。

Gavin King好好的，干嘛不整Hibernate而整Seam。

robbin 写道

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

约定getter/setter是Java的长处，是java的COC,没有这个根本不会有spring，spring的注入就是setter注入。entity bean的setter和getter基本上不是用来注入容器里来的对象的。通常setter和getter都放在开头或者结尾的，根本就不用去阅读，你心里知道有就可以了，甚至都不用它们，它们是给ORM或容器或框架操作的Handler。
而business bean的setter是为参与business上下文过程的功能对象做准备的。

Java是个对象设计语言，所以表述对象之间的关系不是它的长处，它们之间的关系表述和相互作用，用script语言来做再适合不过。Java的script包和OSGi模型就是要引入就是要解决这样的问题的。

用一个简单的语言来描述一个复杂的过程是发展方向。而用复杂的语言描述复杂的东西，复杂的语言描述简单的东西，都不是什么好事。

robbin 写道

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

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

这点，我还是挺赞同的。编程就是一种在集中和分散之间取舍的艺术。

22 楼 laiseeme 2008-12-04  

以后就四个package
entity
manager
controller

util

21 楼 terranhao 2008-12-04  

为什么使用seam能消除DAO？
对一些查询，我还是需要一个DAO来封装啊，要不每次需要select e.* from entity as e where...，我都得调用entitymanager来执行这个sql?
如果用dao,我直接注入一个无状态的dao,然后调用dao就可以了，也避免了代码重复啊
期待解答。

20 楼 netbaixc_gmail_com 2008-12-03  

upheart 写道

[e-mail] 写道
呵呵，职责单一了不就是应对变化啦？具体说，就是一个类就干这个活，不要干A还干B，否则如果仅仅干A的方式改了你就得去改这个类，重新部署测试；DAO就负责持久化的活，像你说的，如果数据库不同了持久化方式要改变则就改DAO；DOMAIN就负责业务逻辑，比如某个财务数据的计算方式变了，就改DOMAIN；Service负责完成用户和系统的基本交互；Command则是针对所有类型的用户交互的服务，因为有些时候有那种“快捷按钮”，你一点就要求系统给你做“一串”处理，所以Command就可以组织发起几个Service。这样按这种分类标准划分的类，哪个方面要变化，就改哪个方面啦。职责似乎可以无限细分下去，这取决于你对变化的预期，如果我预期存储方式99.9%不会变，我是不是就可以先不考虑用一层DAO呢？我做一个web应用，现在也用不着command，没有撤销前进的功能。当然我还是主张职责单一的，我只是不主张无谓的分层。

DAO和DOMAIN看上去不是界限分明的，很明显地为了提高效率往往把可以java运算的业务逻辑用复杂sql表达，相应的domain就架空了，这时domain的方法就直接调用一下dao对象的方法即可，当然有时候可能要发个邮件短信什么的，那指定是不能放到dao里的。DOMAIN和SERVICE也不是界限分明的。但是其实分层的意义在于它是和整个软件工程协作的。我们做软件时总是先定义需求用例，这时候能够划分出command，再从中抽象提炼出service来供command组合调用。一般情况下用户和系统的交互用例都需要事务保护，自然而然地service层里就会体现事务保护，有时还有业务锁同步逻辑。当我们再往下到概要设计时，就会从service里抽象出很业务的domain出来，每个domain都面向比较稳定的业务职责，相互之间也是可以组合调用的，统一交给service来组合调用，这里多数情况又会发现一个service基本上就是调用一个domain，“界限也不是那么分明，何必分层呢”，最后到详细设计实现时那些数据库的活就从domain里明确出来，自然而然地就出来了dao层，当然这时多数情况下又发现一个domain就是调用一个dao拉到，又何必分层呢？呵呵，比较绕。其实分层是这个过程自然的结果，既然这个过程自然产生了分层，何必要抹杀这个成果呢？毕竟分层达到了良好的OO效果，利用代码可读性可维护性，在IOC环境下更加明显。但我其实开始想说的是必须要有辅助工具来帮助程序员面对一个现实，就是这样的分层产生了太多类文件，对于开发人员手工开发起来一不小心打错个字符啥的，还要命名那么多方法，太辛苦啦，开发人员又觉得没有创造性太八股，很难管理啦！虽然设计和需求人员觉得总算可以通过非编程语言和开发人员交流（限制其创造性）了！

19 楼 upheart 2008-12-02  

[e-mail] 写道

呵呵，职责单一了不就是应对变化啦？具体说，就是一个类就干这个活，不要干A还干B，否则如果仅仅干A的方式改了你就得去改这个类，重新部署测试；DAO就负责持久化的活，像你说的，如果数据库不同了持久化方式要改变则就改DAO；DOMAIN就负责业务逻辑，比如某个财务数据的计算方式变了，就改DOMAIN；Service负责完成用户和系统的基本交互；Command则是针对所有类型的用户交互的服务，因为有些时候有那种“快捷按钮”，你一点就要求系统给你做“一串”处理，所以Command就可以组织发起几个Service。这样按这种分类标准划分的类，哪个方面要变化，就改哪个方面啦。

职责似乎可以无限细分下去，这取决于你对变化的预期，如果我预期存储方式99.9%不会变，我是不是就可以先不考虑用一层DAO呢？我做一个web应用，现在也用不着command，没有撤销前进的功能。

当然我还是主张职责单一的，我只是不主张无谓的分层。

18 楼 jerryeye 2008-12-02  

DAO做的事情不做了吗？不做了当然取消，做了却取消，只是搬了个地方而已，这样有意思？DAO只是三个字母而已，惹谁了？大概robbin被国外的"血型"弄的迷糊了。

17 楼 netbaixc_gmail_com 2008-12-02  

upheart 写道

为什么要分层呢？——大部分人是为了分层而分层，比如我们以前的一个做法就是强制一个实体对应一个dao、一个service一个action等等，就像是写八股文章，还美其名曰规范化，为了以后好维护。结果都是一两行的代码在几层之间包来包去。我觉得分层最主要的目的是解耦。很多人可能觉得分层是为了分类职责，这可能是分层带来的一个好处，但不是主要目的。要的目的是解耦，解耦的主要目的是应对变化。比如我分一个dao层，可以屏蔽掉hibernate或jpa或jdbc的具体实现，这样我可以切换不同的实现了。你看spring里边的petstore例子提供了不同的实现。问题是对于变化我们应该什么态度。我觉得应该在三个方面考虑：1.变化发生的可能性和机率；2.提前准备应对这个变化要增加的成本（包括机会成本）3.如果不提前考虑这个变化，以后通过重构来应对的代价。比如你有多大的可能要切换hibernate到jdbc或其他的实现呢？如果hibernate已经被证实足够稳定，那依赖它有什么问题呢？就像你依赖java.util一样是吧。这种被Rod JSon成为“幻影需求”提前为此而分层实在不值得吧。其实就算你分了层以后切换的时候还是会有很多问题的，除非你的应用就像petstore一样简单。所以与其这么做，不如完善你的测试，如果变化来了，有测试做保障，提炼重构付出的代价不一定比你提前预防这种变化的的代价要大很多。而且一定要考虑这种变化的机率的大小。分层的另一个好处是可以做孤立测试，说白了就是分离职责然后单独测试。但我前面说过分离职责不一定要分层的，你可以把业务复杂职责单一的功能放在另外一个类中。我现在的做法是用spring web flow做控制层，不需要java代码，只要xml的flow定义，其中调用service层。这个service层负责事务边界也代理业务，直接使用JPA接口。domain对象除了jpa等元数据的映射，提供一些get方法（我是说计算方法，比如getTotalSize()），还提供一些验证逻辑。页面使用Rich Faces。service测试大部分不做mock，而是连接数据库做测试，spring test框架支持自动回滚，可以用dbunit初始化测试数据就可以了。业务计算复杂的提炼出一个类来可以做mock测试了。可能以后还想加上selenium做验收测试，现在还没有加。

呵呵，职责单一了不就是应对变化啦？具体说，就是一个类就干这个活，不要干A还干B，否则如果仅仅干A的方式改了你就得去改这个类，重新部署测试；DAO就负责持久化的活，像你说的，如果数据库不同了持久化方式要改变则就改DAO；DOMAIN就负责业务逻辑，比如某个财务数据的计算方式变了，就改DOMAIN；Service负责完成用户和系统的基本交互；Command则是针对所有类型的用户交互的服务，因为有些时候有那种“快捷按钮”，你一点就要求系统给你做“一串”处理，所以Command就可以组织发起几个Service。这样按这种分类标准划分的类，哪个方面要变化，就改哪个方面啦。

16 楼 upheart 2008-12-02  

为什么要分层呢？——大部分人是为了分层而分层，比如我们以前的一个做法就是强制一个实体对应一个dao、一个service一个action等等，就像是写八股文章，还美其名曰规范化，为了以后好维护。结果都是一两行的代码在几层之间包来包去。

我觉得分层最主要的目的是解耦。很多人可能觉得分层是为了分类职责，这可能是分层带来的一个好处，但不是主要目的。要的目的是解耦，解耦的主要目的是应对变化。比如我分一个dao层，可以屏蔽掉hibernate或jpa或jdbc的具体实现，这样我可以切换不同的实现了。你看spring里边的petstore例子提供了不同的实现。

问题是对于变化我们应该什么态度。我觉得应该在三个方面考虑：1.变化发生的可能性和机率；2.提前准备应对这个变化要增加的成本（包括机会成本）3.如果不提前考虑这个变化，以后通过重构来应对的代价。

比如你有多大的可能要切换hibernate到jdbc或其他的实现呢？如果hibernate已经被证实足够稳定，那依赖它有什么问题呢？就像你依赖java.util一样是吧。这种被Rod JSon成为“幻影需求”提前为此而分层实在不值得吧。其实就算你分了层以后切换的时候还是会有很多问题的，除非你的应用就像petstore一样简单。所以与其这么做，不如完善你的测试，如果变化来了，有测试做保障，提炼重构付出的代价不一定比你提前预防这种变化的的代价要大很多。而且一定要考虑这种变化的机率的大小。

分层的另一个好处是可以做孤立测试，说白了就是分离职责然后单独测试。但我前面说过分离职责不一定要分层的，你可以把业务复杂职责单一的功能放在另外一个类中。

我现在的做法是用spring web flow做控制层，不需要java代码，只要xml的flow定义，其中调用service层。这个service层负责事务边界也代理业务，直接使用JPA接口。domain对象除了jpa等元数据的映射，提供一些get方法（我是说计算方法，比如getTotalSize()），还提供一些验证逻辑。页面使用Rich Faces。

service测试大部分不做mock，而是连接数据库做测试，spring test框架支持自动回滚，可以用dbunit初始化测试数据就可以了。业务计算复杂的提炼出一个类来可以做mock测试了。

可能以后还想加上selenium做验收测试，现在还没有加。

15 楼 icewubin 2008-12-01  

wangchao_17915566 写道

数据库+展现，剩下的一概不要

你这样不就是分了一层么？“展现”就是你的分层，你的展现如何实现？再分层么？呵呵。

14 楼 czx566 2008-12-01  

wangchao_17915566 写道

数据库+展现，剩下的一概不要

不同意，除非你的业务逻辑都是单纯增删改查

13 楼 wangchao_17915566 2008-12-01  

数据库+展现，剩下的一概不要

12 楼 icewubin 2008-12-01  

引用

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

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

分层未必代码量大，完全是看你打算把什么东西分层，如何分层和分层的粒度问题。有时候更多的是逻辑上的分层，甚至于可以理解为编程规范，分得好或者说理解的好的话，不会增加多少代码和配置的。