Domain Object贫血vs富血(DDD)和spring roo到ruby的扯淡

引子：
前几天，小胖和我说他们公司CTO批他了，说他写的代码不够OO，不够DDD。细问才知道他们CTO在推DDD(领域模型驱动设计).我当时给他的观点是，JavaEE应用是天生贫血的，并不能像ruby之类的语言做到很好的富血，做到DDD。因为这些观点也是N年前讨论过的问题，我记得冒似robbin当年还下过定论：Java天生是贫血的。所以有了ruby之流做RAD快速开发。但当seam到spring roo的出现与完善，富血DDD在Java里也变得可行起来（此论言之尚早，拭目以待）。我以前也和别人争吵过哪个更好，现在我的思想又受到了一些冲击，你呢？世界在发展，我们的思想是不是也应该与时俱进呢？

贫血vs富血

我们来回顾一下。在企业架构模式中，业务层的实现一般有两种模式：一种是事务角本模式（Transaction script），另一种是领域模型模式（Domain Model）。这两种分别对应贫血和富血。好吧，我们不说这些扯淡的东西，我们简单点说。

所谓贫血，就是一个对象里只有属性，如java中的pojo，要实现业务，要依靠service层来实现相关方法，service层的实现是面向过程的，也就是所谓的transaction script.我们现在大量的分层应用action->service->dao->entity的方式就是这种贫血的模式实现。

//贫血代码示例：
Account.java
Public class Account{
	private String name;
	private Long num;
    get set…

}

AccountService.java
Public class AccountService{
	public List findAccountBySomething(String abc){}
	public void addAccount(Account a){}
	public void  otherBiz(){}

}

所谓的富血就是属性和方法都封装在Domain Object里，所有业务都直接操作Domain Object。Service层只是完成一些简单的事务之类的，甚至可以不用service层。也就是直接从action->entity.

//富血代码示例
Account.ava
Public class Account{
	private String name;
	private Long num;

	public List findAccountBySomething(String abc){}
	public void addAccount(Account a){}
	public void  otherBiz(){}
}

前人总结的一些贫血和富血的对比：
贫血模型的优点：
1.被许多程序员所掌握，许多教材采用的是这种模型，对于初学者，这种模型很自然，甚至被很多人认为是java中最正统的模型。
2.它非常简单，对于并不复杂的业务(转帐业务)，它工作得很好，开发起来非常迅速。它似乎也不需要对领域的充分了解，只要给出要实现功能的每一个步骤，就能实现它。
3.事务边界相当清楚，一般来说service的每个方法都可以看成一个事务，因为通常Service的每个方法对应着一个用例。
其缺点为也是很明显的：
1.所有的业务都在service中处理，当业越来越复杂时，service会变得越来越庞大，最终难以理解和维护。
2.将所有的业务放在无状态的service中实际上是一个过程化的设计，它在组织复杂的业务存在天然的劣势，随着业务的复杂，业务会在service中多个方法间重复。
3.当添加一个新的UI时，很多业务逻辑得重新写。例如，当要提供Web Service的接口时，原先为Web界面提供的service就很难重用，导致重复的业务逻辑（在贫血模型的分层图中可以看得更清楚），如何保持业务逻辑一致是很大的挑战。

富血的优点是：
1.领域模型采用OO设计，通过将职责分配到相应的模型对象或Service，可以很好的组织业务逻辑，当业务变得复杂时，领域模型显出巨大的优势。
2.当需要多个UI接口时，领域模型可以重用，并且业务逻辑只在领域层中出现，这使得很容易对多个UI接口保持业务逻辑的一致(从领域模型的分层图可以看得更清楚)。
富血的缺点是：
1.对程序员的要求较高，初学者对这种将职责分配到多个协作对象中的方式感到极不适应。
2.领域驱动建模要求对领域模型完整而透彻的了解，只给出一个用例的实现步骤是无法得到领域模型的，这需要和领域专家的充分讨论。错误的领域模型对项目的危害非常之大，而实现一个好的领域模型非常困难。
3.对于简单的软件，使用领域模型，显得有些杀鸡用牛刀了。
4.对于事务等的处理，如果完全DDD,java支持得不够好。

关于Spring roo
引子中小胖公司就是采用Roo完成DDD富血开发。Spring Roo is a popular open-source rapid application development (RAD) tool for Java developers. ，使用命令行或工具操作来生成自动化项目，操作非常类似于rails。Roo可以很好的支持富血的Java DDD。关于roo我也不想说太多，因为我也没有亲自实战过，大家可以google一下。

如果采用roo,只需要
对于一个业务实现

@Entity  
@RooEntity  
@RooJavaBean  
@RooToString  
public class Employee {   
    @NotNull  
    @Size(max = 200)   
    private String name;   
  
    @Temporal(TemporalType.TIMESTAMP)   
    private Date birth;   
}  

//EmployeeController代码如下： 
@RooWebScaffold(automaticallyMaintainView = true, formBackingObject = Employee.class)   
@RequestMapping("/employee/**")   
@Controller  
public class EmployeeController {   
} 

在这里出现了一行@RooWebScaffold注解，做过rails的人会想，这不是rails里面的scaffold吗？没错，通过@RooWebScaffold注解，EmployeeController自动获得了curd的所有功能。

好了，就这么简单，一个domain，一个Controller，我们就可以发布到tomcat中运行了。

引用

Roo功能目前还不很强大，比如还不能根据配置的数据库链接直接从数据库表来生成Entity，以及前端表示层使用JSP和绑定Spring MVC(基于Spring 3.0支持REST)等，但是这些改进目标已经纳入其roadmap中。说一下另一个框架Seam对于富血也做得不错了，但还不是完全富血，同样也绑带了JSF。

这两天又看了一下spring roo,修正一下观点，新的spring roo版本已经可以用DBRE reverse from db.并且好像也很强大。

1.一个entity只需要写属性就行，get set免。
2.简单的增删改查功能，一键生成。
3.通过aspectJ实现编译时aop，完全不影响性能。
4.可以动态查询：如findPersonByNameAndMinMax(),相当于like name,between min to max这样的功能。
5.用Spring roo实现DDD，只有两层Controller层和Entity层。另外Service层（可选），Dao不推荐用了。
6.jms,email,json序列化支持
7.其它说明：开发需要JDK1.6以上。
8.不想用roo时，可以快速删除annotation和相关的jar包等文件。
...

Spring roo架构overview：




AspectJ实现编译时AOP




自动动态查询，自动生成





想了解更多roo内容，可以看看此文：使用Spring Roo ，感受ROR式的开发
http://www.iteye.com/topic/443059
还有看官方文档：
http://www.springsource.org/roo

关于ruby
Ruby我没有使用过，只是有所了解。所以不敢评价。但是当spring roo等框架成熟起来后，java语言就能很好的支持富血，更好的OO，更好的DDD，也能支持web快速开发了。那么我们能不能斗胆问一句：基于Java的开发者，想实现ror一样的web开发，还需要ruby吗？我们没必要向ruby转了吧？


小结：
我们对于新的东西，总是会有一种天生的阻抗性。就如我习惯了贫血的开发模式，有了更OO的spring roo出现时，我内心里还是不大看好它。正如前些天一些人说spring越来越庞大，不好一样，我想他们也是内心的阻抗性在起作用。但一个人要有一个更高的视野，时刻准备一些东西，当风暴来临时，可以从容面对。

ps:说一下我的观点：
我是多年的贫血模型的实践者，基本上并没什么特别觉得不适的地方，虽然贫血模型不那么OO。其实我对于这个spring roo并不是特别看好。但是需要去了解它，和关注它。(可能又要修正了，看发展情况吧)

国外有一篇文章对spring roo的观点，我是比较赞同的:
When to use Spring roo?
http://java.dzone.com/articles/when-use-spring-roo?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+javalobby%2Ffrontpage+(Javalobby+%2F+Java+Zone)
我抽出几个重要的出来：
What is Spring Roo?
“Spring Roo is a lightweight developer tool that makes it fast and easy to deliver instant results. Best of all, you code 100% in Java and get to reuse all your existing Java knowledge, skills and experience.

Spring Roo is awesome for CRUD-Clients!

Spring Roo is good for learning Technologies!

Spring Roo is NOT good for complex Projects (yet)...

Conclusion: Spring Roo is a nice Tool => Become a Part of the Community!
My final conclusion: You should know Spring Roo, because it is nice, but you should also know when to use it and when to use something else. Use it to create CRUD applications or to learn technologies. Do not use it (yet) for complex, large projects.

基本上结论就是，你必需知道spring roo,因为它确实很好，但是你必需知道什么时候使用它，什么时候使用其它的开发方式。用它来生成简单的，业务不复杂的crud应用，或者只是用来学习新技术。不要使用spring roo来做复杂的，大型的项目。

别人的一些观点：
1.Martin Flowler批贫血的文章：AnemicDomainModel
http://martinfowler.com/bliki/AnemicDomainModel.html

也许在现有的技术和框架支持下，Java的DDD和富血应用已经开始成熟。ruby是否可在java界休止了呢？等待先行实践者分享经验。

欢迎拍砖，谢绝谩骂！

附件为:spring roo快速学习文档

评论

38 楼 piao_bo_yi 2011-04-17  

lzyzizi 写道

我一直有个疑惑，既然是用“贫血模型”那还要什么面向对象的语言。贫血模型和数据结构+函数有什么本质区别么？

在贫血模型周围的框架是用什么编的？

37 楼 peterwei 2011-04-17  

fireflyc 写道

说java中做不了DDD，这种话本身就是一种不负责的话。xxx当年还吹嘘过各种各样的技术。都是浮云，做一个负责的人吧。

哈哈，那么说ruby可有可无了。

36 楼 peterwei 2011-04-17  

fireflyc 写道

哎，看了楼主的介绍我觉得，楼主对领域驱动设计认识似乎是有问题的，而且我感觉基本上很多人都是存在这样的一个误区。

认为service和entity和DAO合并在一起，就是领域驱动了，比如之前是
Student,StudentDAO(或者泛型DAO),StudentService现在只有一个Student来干所有的事情。

我觉得持有这种观点的人是对DDD的理解有问题的，DDD中最为突出的5辆马车，Entity，Value Object，Factory，Service，Repository，这里可是也有entity也有vo，也有service的。只此一例来证明楼主对DDD的理解有偏差。

我承认我对DDD了解不深。那么，DDD应该是吧数据和逻辑放在一起吧？service层应该不管逻辑的事吧，应该只是浅浅的一层。那么dao,service是可有可无吧，从spring roo可以看到一斑。如果你有DDD实践经验，那么你认为DDD在国内是否已经成熟，是否可以在实际的项目中推广了？推广的难度是什么？为什么大家还在用贫血的模式？

35 楼 fireflyc 2011-04-17  

说java中做不了DDD，这种话本身就是一种不负责的话。xxx当年还吹嘘过各种各样的技术。都是浮云，做一个负责的人吧。

34 楼 fireflyc 2011-04-17  

哎，看了楼主的介绍我觉得，楼主对领域驱动设计认识似乎是有问题的，而且我感觉基本上很多人都是存在这样的一个误区。

认为service和entity和DAO合并在一起，就是领域驱动了，比如之前是
Student,StudentDAO(或者泛型DAO),StudentService现在只有一个Student来干所有的事情。

我觉得持有这种观点的人是对DDD的理解有问题的，DDD中最为突出的5辆马车，Entity，Value Object，Factory，Service，Repository，这里可是也有entity也有vo，也有service的。只此一例来证明楼主对DDD的理解有偏差。

33 楼 peterwei 2011-04-17  

sulong 写道

DDD不是一门纯粹的软件设计学问，还是一个软件过程理论。做DDD，前提是要与领域专家充分交互，共同给领域建模，再把领域模型与代码绑定。 DDD也不一定非要用面向对象的方式建模，还可以用建规则模型，数学模型等，只不过面向对象在大部分情况下是最容易建模的。脱离了领域，程序员看到的都是技术问题，是不可能实现DDD的。DDD并不违反面向对象，面向对象要求类要单一职责，所以不应该出现所谓的“充血模型”，一定类只做它该做的事，只会恰到好处，不会血多到要涨。如果一个类太复杂，太大，那说明模型上有些地方要更加的细化了，对应的代码也要更加细化，职责重新划分。DDD也是要迭代中进行的，模型要不断完善，代码也要跟着不断完善。

你说的没错，但是我们现在想知道在java中，DDD如何具体的落地。而不是想听到高谈阔论，大谈理论。如service层这些要不要，在应用中的架构是怎么样的？用到哪些技术，如spring roo.对于复杂的业务，如多个domain的互相调用协调是如何处理的？在应用DDD中，会出现什么样的问题?以后维护会不会方便。。。

32 楼 peterwei 2011-04-17  

ppgunjack 写道

比如GIS，点线面class本身承载数据和包含很少的自身的方法，而空间运算都是放在算法逻辑中，而不是数据类中，这样的结构很清晰，复用性也很强
而DAO就是典型的Dao.save(X|Y|Z),这样的结构也很清晰
所以逻辑放在那个地方取决于应用的特性
而电信设备数据系统就是fn(n*A，m*B)->C，D这种特性的逻辑很多，所以service抽出来是更合理的设计

其实我和你的观点基本上是一致的。我也是想知道搞DDD这帮人是怎么弄的。

31 楼 sulong 2011-04-17  

DDD不是一门纯粹的软件设计学问，还是一个软件过程理论。做DDD，前提是要与领域专家充分交互，共同给领域建模，再把领域模型与代码绑定。 DDD也不一定非要用面向对象的方式建模，还可以用建规则模型，数学模型等，只不过面向对象在大部分情况下是最容易建模的。脱离了领域，程序员看到的都是技术问题，是不可能实现DDD的。DDD并不违反面向对象，面向对象要求类要单一职责，所以不应该出现所谓的“充血模型”，一定类只做它该做的事，只会恰到好处，不会血多到要涨。如果一个类太复杂，太大，那说明模型上有些地方要更加的细化了，对应的代码也要更加细化，职责重新划分。DDD也是要迭代中进行的，模型要不断完善，代码也要跟着不断完善。

30 楼 ppgunjack 2011-04-17  

比如GIS，点线面class本身承载数据和包含很少的自身的方法，而空间运算都是放在算法逻辑中，而不是数据类中，这样的结构很清晰，复用性也很强
而DAO就是典型的Dao.save(X|Y|Z),这样的结构也很清晰
所以逻辑放在那个地方取决于应用的特性
而电信设备数据系统就是fn(n*A，m*B)->C，D这种特性的逻辑很多，所以service抽出来是更合理的设计

29 楼 peterwei 2011-04-17  

对于你上面所说的这种问题。应该指的是方法逻辑划分在哪个domain下面更合适。这就要搞domain model的人既要很懂领域知识，又要有丰富的设计经验才行，能事先看到以后的一些问题，并避免那样的问题发生。所以我也觉得ddd,一旦设计不好，就会带出很多问题，包括domain间逻辑的反复变化。

28 楼 ppgunjack 2011-04-17  

db就理解成B就好了

27 楼 peterwei 2011-04-17  

ppgunjack 写道

把数据(domain)和方法（放在Service层）分开,有违OO的封装的原则
不能一概而论，这要考虑A contact B这个很有广泛性形式的业务转化成A、B、contact谁主导的问题，没有绝对不变的答案
Db.save(A),A.save(DB),save(DB,A),
我觉得其实第三种是侵入最小，最容易复用和重构的，尤其是在对三者职能划分还没理解透的情况下
很多时候其实很难判断一个方法应该在域模型还是放到专属service对象

没怎么明白你上面的逻辑。db是什么东西？你是不是指关联对象？比如计算费用
那么我们Account.bill(OtherDomain)行不行呢？bill内部有处理逻辑呀。

ppgunjack 写道

OO更适合处理树形继承关系，问题在于对象和对象远不止这种关系，所以需要第三方的manager去处理那些继承和多态不好覆盖的逻辑

我觉得DDD+设计模式应该可以处理好这样的东西。

26 楼 ppgunjack 2011-04-17  

把数据(domain)和方法（放在Service层）分开,有违OO的封装的原则
不能一概而论，这要考虑A contact B这个很有广泛性形式的业务转化成A、B、contact谁主导的问题，没有绝对不变的答案
Db.save(A),A.save(DB),save(DB,A),
我觉得其实第三种是侵入最小，最容易复用和重构的，尤其是在对三者职能划分还没理解透的情况下
很多时候其实很难判断一个方法应该在域模型还是放到专属service对象

是否复用我觉得和是不是把方法放进class其实没关系，而是是否遵循了最小依赖设计的原则
RDBMS的范式设计其实就是实体表--关系表---实体表这样的一种设计体现，关系的抽出让实体更加纯粹，OO与DB最难调和的恰恰是继承多态这些关系

OO更适合处理树形继承关系，问题在于对象和对象远不止这种关系，所以需要第三方的manager去处理那些继承和多态不好覆盖的逻辑

25 楼 peterwei 2011-04-17  

yangyi 写道

除非能够抛弃关系型数据库，否则对此不抱乐观。ORM从某种程度上说，并没有取得成功，OO的视角是流转的数据，而DB的视角是数据的流转，这种矛盾从架构上是不可调和的。除非能够在业务系统中淡化数据库的角色（隔离它），或者干脆用新的持久化方法（取代它）。原因还是和上面说的一样，数据库的访问方式决定了它的侵入性。

ORM不就是隔离DB的手段嘛。ORM本身就是来调合这些东西的，所以有hibernate的盛行。ORM至少从多年应用来看，还是算成功的。我想现在，甚至几年前的DDD实践者应该都用的是关系数据库吧。面向OO对象的DB，要盛行应该不会是10年之内的事。

24 楼 peterwei 2011-04-17  

yangyi 写道

无语中，已经变成一场否定OO的讨论了

为什么有这样的感想？虽然我大多数时间都在用贫血的东西。但DDD，应该是更OO才对吧？

23 楼 yangyi 2011-04-17  

无语中，已经变成一场否定OO的讨论了

22 楼 peterwei 2011-04-17  

lzyzizi 写道

我一直有个疑惑，既然是用“贫血模型”那还要什么面向对象的语言。贫血模型和数据结构+函数有什么本质区别么？

虽然贫血模型把数据(domain)和方法（放在Service层）分开,有违OO的封装的原则，但OO还有很多其它的特性和原则，还有设计模式等。所以用Java这种80%的OO语言，也没什么大不了吧。更何况还有j2ee without ebj的盛行，和hibernate这些o/r mapping的框架，有pojo,在国内外java盛行也正常了。虽然现在java有很多人垢病，但还是我们赖以生存的谋手生段。

21 楼 peterwei 2011-04-17  

ppgunjack 写道

错误的领域模型对项目的危害非常之大，而实现一个好的领域模型非常困难。
当业务变得复杂时，领域模型显出巨大的优势

这两句不矛盾吗？

见过的电信标准亲一色都是数据service分离 ，各种各样的manager协调着各方数据
Unix管道的设计哲学是富血还是贫血，面向过程还是面向对象

多少人会把应该写成Add（a，b）的写成a.add(b)
以前写过电信设备inventory系统，得到的体会就是尽量把数据和处理分离，对象当成操作数，而不是操作的主体调用者，除非是它自己的吃喝拉撒，很多方法最早在域对象，后面都被移出去，做了很多无用功，最后的代码越来越接近标准接口的风格
在对象当中加方法太危险，用的时候很开心很方便，当方觉模型出问题的时候很揪心，尤其是被继承 扩散后
看到很多牛人的blog都是倾向c而不是c++来重新构建他们的系统，而且还不是因为性能
框架永远解决的是繁琐而简单的问题，最好让他们止于粘合层，能解决复杂问题的东西叫做产品

1.矛盾的那句话是别人说的，我并没有实践过DDD.
2.确实，我相信国内的大多数的javaee应用，都是贫血模型驱动的。我也做过不少电信行业的项目，基本上是你说的情况。但是吃喝拉撒放在一起的情况也很少见呀。
3.因为贫血模型不是那么OO，不好复用Domain逻辑，所以有人批呀。如：
Martin Flowler批贫血的文章：AnemicDomainModel
http://martinfowler.com/bliki/AnemicDomainModel.html
4.而且现在确实也有人在实践DDD，成效怎样并不知道。能看到有人现身说法就好了。

20 楼 lzyzizi 2011-04-17  

我一直有个疑惑，既然是用“贫血模型”那还要什么面向对象的语言。贫血模型和数据结构+函数有什么本质区别么？

19 楼 ppgunjack 2011-04-17  

错误的领域模型对项目的危害非常之大，而实现一个好的领域模型非常困难。
当业务变得复杂时，领域模型显出巨大的优势

这两句不矛盾吗？

见过的电信标准亲一色都是数据service分离 ，各种各样的manager协调着各方数据
Unix管道的设计哲学是富血还是贫血，面向过程还是面向对象

多少人会把应该写成Add（a，b）的写成a.add(b)
以前写过电信设备inventory系统，得到的体会就是尽量把数据和处理分离，对象当成操作数，而不是操作的主体调用者，除非是它自己的吃喝拉撒，很多方法最早在域对象，后面都被移出去，做了很多无用功，最后的代码越来越接近标准接口的风格
在对象当中加方法太危险，用的时候很开心很方便，当方觉模型出问题的时候很揪心，尤其是被继承 扩散后
看到很多牛人的blog都是倾向c而不是c++来重新构建他们的系统，而且还不是因为性能
框架永远解决的是繁琐而简单的问题，最好让他们止于粘合层，能解决复杂问题的东西叫做产品