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），另一种是领域模型模式—omain Model）。这两种分别对应贫血和富血。好吧，我们不说这些扯淡的东西，我们简单点说。
所谓贫血，就是一个对象里只有属性，如java中的pojo，要实现业务，要依靠service层来实现相关方法，service层的实现是面向过程的，也就是所谓的transaction script.我们现在大量的分层应用action->service->dao->entity的方式就是这种贫血的模式实现。
//贫血代码示例：Account.javaPublic class Account{private String name;private Long num; get set…}AccountService.javaPublic class AccountService{public List findAccountBySomething(String abc){}public void addAccount(Account a){}public void otherBiz(){}}所谓的富血就是属性和方法都封装在Domain Object里，所有业务都直接操作Domain Object。Service层只是完成一些简单的事务之类的，甚至可以不用service层。也就是直接从action->entity.
//富血代码示例Account.avaPublic 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中运行了。
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快速学习文档
改变别人的想法是扯淡的事情。。。
如果靠说就能改变别人，你以为你是naruto啊 。。
如果用自己的思想重写代码在给其它技术看，那真的是一个漫长的过程，而且你写出来以后，别人也会觉得，”这样也可以，那样也可以嘛”，结果是没有结果
所以，最最最最最可行的办法是你当老大，你说的算
Spring Roo的问题是过于想包办一切，甚至自己搞了一套预编译命令，验证前端什么都想由框架处理，不出问题还好，出了问题就很难解决。另外Spring Roo的扩展性不高，做复杂的业务是不适合的。我们曾经考虑过使用Spring Roo，但是经过调研以后，还是自己实现了一套框架。你也可以看成是Spring Roo的无侵入性的简化版。底层ORM也利用ibatis重新构建了一遍，放弃了JPA，构造上非常轻量简单。
我们自己的充血框架也在项目中使用了，虽然还没有正式上线，不过测试中表现良好。在开发速度，开发效率各项指标上表现优异。代码行数是贫血版java行数1/5-1/3左右。
过几个月正式上线以后，如果没有大问题，会争取将框架开源的。
Spring Roo的问题是过于想包办一切，甚至自己搞了一套预编译命令，验证前端什么都想由框架处理，不出问题还好，出了问题就很难解决。另外Spring Roo的扩展性不高，做复杂的业务是不适合的。我们曾经考虑过使用Spring Roo，但是经过调研以后，还是自己实现了一套框架。你也可以看成是Spring Roo的无侵入性的简化版。底层ORM也利用ibatis重新构建了一遍，放弃了JPA，构造上非常轻量简单。
我们自己的充血框架也在项目中使用了，虽然还没有正式上线，不过测试中表现良好。在开发速度，开发效率各项指标上表现优异。代码行数是贫血版java行数1/5-1/3左右。
过几个月正式上线以后，如果没有大问题，会争取将框架开源的。
真有你说的那么好吗？拭目以待。我赌你们肯定参考了别人的东西。可以申请开源，让大家看看。
88 楼 飞雪无情 2011-04-29 tedeyang 写道贫血富血与service、dao等没有必然联系。
service一般是被视为面向接口设计和facade模式，所谓“服务层”，意义是很清楚的，只是提供业务逻辑层的统一包装和调用，这一层与DDD也没有任何冲突。DAO也如此。
很认同这个观点，层级关系清晰，职责明确，该是做什么的就是做什么的 89 楼 飞雪无情 2011-04-29 peterwei 写道
像spring roo这种东西，基本上是srpingmvc（Controller）-->domain了，也就是说不用service层和dao层了。把一些事务和其它的东西交给spring去做了，这也就是spring越来越大的原因之一。我发这个贴子，是想看看有多少人在用spring roo来做ddd,以及他们处理复杂逻辑的经验。
我不是很认同srpingmvc（Controller）-->domain这样的模式，虽然这样可以DDD，但是对于层级之间的关系和职责就不是很清晰了，也要导致srpingmvc（Controller）变得很大，很慢，很不好处理。。
90 楼 飞雪无情 2011-04-29 whaosoft 写道唉 和lz想法一致啊 感觉spring越来越胖了 有点ejb2的影子了
是啊，当年Spring刚出的时候多好，多么轻，就因为这个才用它的，现在是越来越大了，臃肿 91 楼 飞雪无情 2011-04-29 peterwei 写道zhyuan 写道不建议使用在大型系统中使用自动化代码生成工具，不管是自己开发的还是开源的，自己开发的代码生成工具还好，开源的出了问题就麻烦了。开发的时间节省了，维护的时间却大大的增加了。
前些天我们公司的开发工程师向我提议说要不要采用0配置，全部采用注解等。我基本上不赞同的，基本上用xml配置文件，分好层和模块了，以后几个项目庞大时，因为有好几个子系统，更好理解和以后维护一些。
嗯，分层和分模块之后更容易维护和开发，也能更容易理解。因为团队不是你一个人，那是很多人在协同开发。 92 楼 icefire 2011-04-29 最近看了jbpm4。
感觉比较靠近ddd。
而且相对来说，jbpm4中service和entity职责划分挺好。
jbpm4整个又是大量使用了命令模式，使得service很简单，真的成为一个单纯的对外接口。
总之jbpm4的参考价值还是很大的。 93 楼 manysysy 2011-04-30 一种是事务角本模式（Transaction script）
应该是事务脚本吧 94 楼 key232323 2011-05-01 为什么总想着绕开“SQL”——SQL有那么不好么。。。
刚看了下那个roo自动生成的那么一堆findBy方法，疯了——还比如自己写个动态sql生成的简单（起码只有一个方法），字段变了还要重新生成？
基于数据库的应用本来就没那么多事儿，业务复杂了，也不用把和数据库交互这块弄得这么深——很多情况下，只用SQL，简单的事务，kiss啊 95 楼 peterwei 2011-05-01 key232323 写道为什么总想着绕开“SQL”——SQL有那么不好么。。。
刚看了下那个roo自动生成的那么一堆findBy方法，疯了——还比如自己写个动态sql生成的简单（起码只有一个方法），字段变了还要重新生成？
基于数据库的应用本来就没那么多事儿，业务复杂了，也不用把和数据库交互这块弄得这么深——很多情况下，只用SQL，简单的事务，kiss啊
当我们用hibernate这些orm东西的时候，我们已然在避开sql.这个没什么好说的。如果只是简单的crud操作，用hibernate还是非常能提高各方面效率的。当然复杂的业务，hibernate也能做，前提是把hibernate用好了。但实在太复杂的时候，简单的sql确实比较高效，这方面直接spring的模板就完事。很多的情况下，crud占了80-90%以上，这样注定了hibernate的流行。 96 楼 key232323 2011-05-02 peterwei 写道key232323 写道为什么总想着绕开“SQL”——SQL有那么不好么。。。
刚看了下那个roo自动生成的那么一堆findBy方法，疯了——还比如自己写个动态sql生成的简单（起码只有一个方法），字段变了还要重新生成？
基于数据库的应用本来就没那么多事儿，业务复杂了，也不用把和数据库交互这块弄得这么深——很多情况下，只用SQL，简单的事务，kiss啊
当我们用hibernate这些orm东西的时候，我们已然在避开sql.这个没什么好说的。如果只是简单的crud操作，用hibernate还是非常能提高各方面效率的。当然复杂的业务，hibernate也能做，前提是把hibernate用好了。但实在太复杂的时候，简单的sql确实比较高效，这方面直接spring的模板就完事。很多的情况下，crud占了80-90%以上，这样注定了hibernate的流行。
Ibatis Spring JdbcTemplate都在5年前用过，虽然项目小，但开发过程一样没见得简化多少，而hibernate的entity对象，不管是xml还是annotation，个人感觉在贫血的情况下甚至没有出现在项目中的必要——每一层都可以以coc的形式约定就好，一直到数据库表，1:m m:m也没那么复杂。 顺便问下使用hibernate的童鞋，假设一个数据库表的设计合理，有50-100个字段，做一个增删改查，是不是也要写一个庞大的bean？ 97 楼 peterwei 2011-05-02 key232323 写道peterwei 写道key232323 写道为什么总想着绕开“SQL”——SQL有那么不好么。。。
刚看了下那个roo自动生成的那么一堆findBy方法，疯了——还比如自己写个动态sql生成的简单（起码只有一个方法），字段变了还要重新生成？
基于数据库的应用本来就没那么多事儿，业务复杂了，也不用把和数据库交互这块弄得这么深——很多情况下，只用SQL，简单的事务，kiss啊
当我们用hibernate这些orm东西的时候，我们已然在避开sql.这个没什么好说的。如果只是简单的crud操作，用hibernate还是非常能提高各方面效率的。当然复杂的业务，hibernate也能做，前提是把hibernate用好了。但实在太复杂的时候，简单的sql确实比较高效，这方面直接spring的模板就完事。很多的情况下，crud占了80-90%以上，这样注定了hibernate的流行。
Ibatis Spring JdbcTemplate都在5年前用过，虽然项目小，但开发过程一样没见得简化多少，而hibernate的entity对象，不管是xml还是annotation，个人感觉在贫血的情况下甚至没有出现在项目中的必要——每一层都可以以coc的形式约定就好，一直到数据库表，1:m m:m也没那么复杂。 顺便问下使用hibernate的童鞋，假设一个数据库表的设计合理，有50-100个字段，做一个增删改查，是不是也要写一个庞大的bean？
你这是纯属抬杠。哈哈。你怎么不说500个字段呢？在我们做过的大多数项目里，哪有出现那么多字段的。你这是拿特例来说事。特例自然有特例的处理方法。比如一些报表系统，有很多字段的。可以事前统计，做物化视图等。对于海量的数据，自然有相应的处理技术。这些都不是hibernate擅长的地方，也就是剩下那10%左右不能做的事情。 98 楼 hypercube1024 2011-05-02 IcyFenix 写道downpour 写道一个没写过超过1000w行代码的人，我认为连说OO的资格都没有。
你是不是多打了一两个零？
这个世界上有多少人能写过超过1000w行代码？
1000W行，代码写的多好像也不能说明什么问题，用不用OO和能否写出好软件没什么必然联系吧~~~