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快速学习文档

评论

78 楼 peterwei 2011-04-21  

引用

说到整体，有状态的EJB不正是干Rich Object的吗，有人说性能不好怎么低，复杂，都是瞎扯。首先，看看业务和开发效率，难道Rich就不能OOP吗？只要是Java对象都能OOP，只代码风格和关注点不同。

banq那帮人应该就是搞这个Rich的。好吧，07年的时候我也搞过半年ejb,但是当时两个架构师否决了ejb,从此一直走在spring道路上。实际上Rich在开发速度上确实很快，我有过小段时间的实践。但是很多人担心业务越来越复杂后，可维护性的问题。我其实也有这个担心，所以不敢说特别坚定，只能说拭目以待。

77 楼 mercyblitz 2011-04-21  

peterwei 写道

mercyblitz 写道

我又上来骂一句，呵呵。

当年整出什么Core J2EE设计模式，VO，DAO，Service，Facade出现了，当时人们眼前一亮，我靠，原来世界上面可以把层次分析得怎么清晰。后来，随着项目的扩大，又不行了。又跳出来骂，妈的，搞这么多测试，DAO都搞个接口，一大堆Service，Manager在里面。老子还不如搞一个Util类去处理。这个时候，又反思为什么太多的DO或者VO作为贫血对象，我习惯成为Thin Object,而相反为Rich Object。

我记得一次和某CTO分析系统时，我提出JSF和EJB的方案，被他批评了，他认为层次华清晰地MVC是一个银弹，我对他说确实很“淫——荡”。

很多系统架构师很容易被洗脑，很少去看非主流技术。

说到整体，有状态的EJB不正是干Rich Object的吗，有人说性能不好怎么低，复杂，都是瞎扯。首先，看看业务和开发效率，难道Rich就不能OOP吗？只要是Java对象都能OOP，只代码风格和关注点不同。

对不起，我又冲动了！

那你Rich了吗？你们的团队Rich了吗？说实话，我们现在的团队，还是老一套，走主流的一套。是Web应用.
web层-vo(将来可能rmi or hessian)-spring-po-dao-hibernate.今天讨论还有个小弟提出0配置和无vo、无接口方式,他说我们是为了接口而接口。哈哈。结果当然是部门经理主流派战胜，有权嘛。我做为夹心层，只能分析各自的优缺点，然后稍偏向小弟。但是说了一句：各有优缺点，这个由老大拍板。但其实thin的也挺好的。

官大一级压人呀！多元化的思想，很难形成规模！

76 楼 peterwei 2011-04-21  

mercyblitz 写道

我又上来骂一句，呵呵。

当年整出什么Core J2EE设计模式，VO，DAO，Service，Facade出现了，当时人们眼前一亮，我靠，原来世界上面可以把层次分析得怎么清晰。后来，随着项目的扩大，又不行了。又跳出来骂，妈的，搞这么多测试，DAO都搞个接口，一大堆Service，Manager在里面。老子还不如搞一个Util类去处理。这个时候，又反思为什么太多的DO或者VO作为贫血对象，我习惯成为Thin Object,而相反为Rich Object。

我记得一次和某CTO分析系统时，我提出JSF和EJB的方案，被他批评了，他认为层次华清晰地MVC是一个银弹，我对他说确实很“淫——荡”。

很多系统架构师很容易被洗脑，很少去看非主流技术。

说到整体，有状态的EJB不正是干Rich Object的吗，有人说性能不好怎么低，复杂，都是瞎扯。首先，看看业务和开发效率，难道Rich就不能OOP吗？只要是Java对象都能OOP，只代码风格和关注点不同。

对不起，我又冲动了！

那你Rich了吗？你们的团队Rich了吗？说实话，我们现在的团队，还是老一套，走主流的一套。是Web应用.
web层-vo(将来可能rmi or hessian)-spring-po-dao-hibernate.今天讨论还有个小弟提出0配置和无vo、无接口方式,他说我们是为了接口而接口。哈哈。结果当然是部门经理主流派战胜，有权嘛。我做为夹心层，只能分析各自的优缺点，然后稍偏向小弟。但是说了一句：各有优缺点，这个由老大拍板。但其实thin的也挺好的。

75 楼 mercyblitz 2011-04-21  

我又上来骂一句，呵呵。

当年整出什么Core J2EE设计模式，VO，DAO，Service，Facade出现了，当时人们眼前一亮，我靠，原来世界上面可以把层次分析得怎么清晰。后来，随着项目的扩大，又不行了。又跳出来骂，妈的，搞这么多测试，DAO都搞个接口，一大堆Service，Manager在里面。老子还不如搞一个Util类去处理。这个时候，又反思为什么太多的DO或者VO作为贫血对象，我习惯成为Thin Object,而相反为Rich Object。

我记得一次和某CTO分析系统时，我提出JSF和EJB的方案，被他批评了，他认为层次华清晰地MVC是一个银弹，我对他说确实很“淫——荡”。

很多系统架构师很容易被洗脑，很少去看非主流技术。

说到整体，有状态的EJB不正是干Rich Object的吗，有人说性能不好怎么低，复杂，都是瞎扯。首先，看看业务和开发效率，难道Rich就不能OOP吗？只要是Java对象都能OOP，只代码风格和关注点不同。

对不起，我又冲动了！

74 楼 peterwei 2011-04-21  

icewind_yx 写道

领域模型只是一种思路，为什么没有流行起来是因为没有真正能够支持领域模型的充血Domain Object框架存在，Rails靠近了这个思路。由于java死板的语法的原因，在java中实现Domain Object，现在来说还不现实。除非再出现一个类似Hibernate那样划时代的Domain Object ORM框架出来。

另外：
Spring Roo只适合做DEMO，或者说是一种前进道路上的不成功的尝试，真实的业务问题使用Spring Roo是不行的。

又另外：
我们自己也做了一个java充血模型框架，可以说的是比Spring Roo要好一些。但是依然解决不了领域模型框架的问题，可以说纯领域模型框架在现阶段是不存在的。

好像这个思路已经有很多年了。你说Spring roo只适合做demo,但真的有些人开始在真的项目中使用了，如引子所说的CTO.我想应该有一定的成熟度和可行性了，要不然别人不会冒然行事。
哈哈，居然比Spring Roo还好些，口气不小嘛。你们参考了Spring roo了吗？万一能解决你们的问题呢？隐约能猜到你所在的公司，好像是我以前接触过的一家公司。

73 楼 icewind_yx 2011-04-21  

领域模型只是一种思路，为什么没有流行起来是因为没有真正能够支持领域模型的充血Domain Object框架存在，Rails靠近了这个思路。由于java死板的语法的原因，在java中实现Domain Object，现在来说还不现实。除非再出现一个类似Hibernate那样划时代的Domain Object ORM框架出来。

另外：
Spring Roo只适合做DEMO，或者说是一种前进道路上的不成功的尝试，真实的业务问题使用Spring Roo是不行的。

又另外：
我们自己也做了一个java充血模型框架，可以说的是比Spring Roo要好一些。但是依然解决不了领域模型框架的问题，可以说纯领域模型框架在现阶段是不存在的。

72 楼 peterwei 2011-04-19  

hatedance 写道

看不下去了，我来简单地告诉你们什么是ddd。具体的去jdon看看。
ddd就是利用ORM和AOP屏蔽数据库的sql和事务。比如
bool login（userid,password）;
{
User user = repository.get(User.class,userid);
return user.checkpassword(password);
}
而不是select * from users where userid=? and password=?
比如学生选课
student.addClass(class){this.classes.put(class);}
repository.update(student);//此处级联更新新增的class
而不是insert into classes values(....)

总之，这种代码几乎看不到sql，看不到commit，仿佛一切都在内存的集合里。hibernate的session基本上直接拿来当repository用就好了。

但显然DDD有其适合场景，有些时候性能成为大问题，必须用hql,甚至sql等办法来解决。

不管怎么样，select是必然要的。你说的这些根本代表不了DDD.很多贫血模式都是这么应用的。

71 楼 li2005 2011-04-19  

<p> </p>
<div class="quote_title">引用楼主</div>
<div class="quote_div">说一下另一个框架Seam对于富血也做得不错了，但还不是完全富血，同样也绑带了JSF。</div>
<p><br><br>楼主，关于JSF的评论我不太同意，JSF封装了很多功能，很多组件，减轻了程序员很多工作。<br>空说无凭，给大家看些例子吧<br><br>这个是pickList　http://livedemo.exadel.com/richfaces-demo/richfaces/pickList.jsf?c=pickList<br>这个是tree http://livedemo.exadel.com/richfaces-demo/richfaces/tree.jsf?c=tree&amp;tab=usage<br><br>个人觉得，学了JSF，页面上的压力大大减少了</p>
<p> </p>

70 楼 Silverside 2011-04-19  

peterwei 写道

sulong 写道

各位，不如把《领域驱动设计》那本书看一看，如果连这一方法学的经典书藉都没有看过，这样讨论没有多大意义。

DDD的好处不仅仅体现在代码上。它要解决的领域与实现的矛盾，不是具体的技术手段。具体的技术手段，就只强调独立的领域层代码，及模型绑定代码。其它的都是一些具体的技巧了。

书是好书，看过也不能代表什么。如果DDD，真的是银弹，我相信肯定早就流行了。它不流行，必要有它的缺点和局限性。

是因为现实的功利性。

69 楼 Silverside 2011-04-19  

semmy 写道

我有三点疑问：
1、同样当业务逻辑变得越来越复杂时，富血的领域对象也将变得越来越复杂，难以维护，如何解决？
2、在领域对象中封装了太多的方法或属性，是否有必要，可见性等等会不会造成更加混乱，如何解决？
3、还有这样的领域对象是否适合做DTO呢？
这样理解第二点疑问：

public class clsA{
method1();
method2();
method3();

}
public class clsB{
//需要调用method1，但不能调用method2、method3
}
public class clsC{
//需要调用method2，但不能调用method1
}

1、同样当业务逻辑变得越来越复杂时，富血的领域对象也将变得越来越复杂，难以维护，如何解决？
2、在领域对象中封装了太多的方法或属性，是否有必要，可见性等等会不会造成更加混乱，如何解决？
3、还有这样的领域对象是否适合做DTO呢？

说明你不了解领域对象的划分。一个好的对象系统，被清晰的划分出来后，不会有这些问题。这个很考验BA和Architect.

68 楼 ppgunjack 2011-04-19  

DAO不用还是缺乏远期规划，现在产品就在考虑将异步调用队列，和消息序列化转向nosql，焦点不应总放在orm和dao上，service的厚度就真那么薄吗

service 本身的对象是不太会被序列化，所以不能简单看成充血对象，方法是service的骨架，属性是皮毛，这和域对象特点相反

如果一个项目RAD的部分占了大头，通常都是生命周期会很短的产品，复用的目标就更达不到了

67 楼 hatedance 2011-04-19  

看不下去了，我来简单地告诉你们什么是ddd。具体的去jdon看看。
ddd就是利用ORM和AOP屏蔽数据库的sql和事务。比如
bool login（userid,password）;
{
User user = repository.get(User.class,userid);
return user.checkpassword(password);
}
而不是select * from users where userid=? and password=?
比如学生选课
student.addClass(class){this.classes.put(class);}
repository.update(student);//此处级联更新新增的class
而不是insert into classes values(....)

总之，这种代码几乎看不到sql，看不到commit，仿佛一切都在内存的集合里。hibernate的session基本上直接拿来当repository用就好了。

但显然DDD有其适合场景，有些时候性能成为大问题，必须用hql,甚至sql等办法来解决。

66 楼 neverforget 2011-04-19  

peterwei 写道

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在国内是否已经成熟，是否可以在实际的项目中推广了？推广的难度是什么？为什么大家还在用贫血的模式？

如果将传统贫血中的SERVICE看作 充血模型中的ENTITY那他们有区别是啥？

认同楼上的观点 充血模型并不一定要去掉DAO service 而是让ENTITY具有它特有 自身行为的放其ENTITY中实现 作为一个对像整体出现 另外一些交互 或是可能会常变动的业务 在SERVICE层去实现


混血儿最靓了

65 楼 neverforget 2011-04-19  

itstarting 写道

引用

3.对于简单的软件，使用领域模型，显得有些杀鸡用牛刀了。

我到觉得简单的软件用领域模型更方便点。

+1

同意此观点

64 楼 peterwei 2011-04-19  

kongruxi 写道

我对DDD也不是十分清楚，不过介绍个网站
http://www.jdon.com/
这个站长对DDD研究得挺深入的

这个网站，也许我比你去得更早，05年的时候经常去。自从robbin和banq开干后，我就慢慢转到javaeye来了。banq是搞ejb出身的，想当然要搞DDD.我那会是从hibernate的潮流。

63 楼 kongruxi 2011-04-18  

我对DDD也不是十分清楚，不过介绍个网站
http://www.jdon.com/
这个站长对DDD研究得挺深入的

62 楼 peterwei 2011-04-18  

引用

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




自动动态查询，自动生成

61 楼 piao_bo_yi 2011-04-18  

1.从维护性上看，将业务逻辑集中在Service层更容易实现开闭原则。
2.程序员写的代码要符合架构整体风格。比起所谓的贫血模型和富血模型来看，一会这个风格，一会另一个风格，更不容易维护。如果说Service层复杂，说明业务本身就复杂，或者Service没有分好。
3.至于xml配置和注解配置方式，应该是xml配置更容易维护。注解配置适合快速原型开发，所以我个人觉得做原型的时候用TDD加一套快速开发工具，等真正实现，用更清晰的解耦即可。

60 楼 peterwei 2011-04-18  

sulong 写道

各位，不如把《领域驱动设计》那本书看一看，如果连这一方法学的经典书藉都没有看过，这样讨论没有多大意义。

DDD的好处不仅仅体现在代码上。它要解决的领域与实现的矛盾，不是具体的技术手段。具体的技术手段，就只强调独立的领域层代码，及模型绑定代码。其它的都是一些具体的技巧了。

书是好书，看过也不能代表什么。如果DDD，真的是银弹，我相信肯定早就流行了。它不流行，必要有它的缺点和局限性。

59 楼 sulong 2011-04-18  

各位，不如把《领域驱动设计》那本书看一看，如果连这一方法学的经典书藉都没有看过，这样讨论没有多大意义。

DDD的好处不仅仅体现在代码上。它要解决的领域与实现的矛盾，不是具体的技术手段。具体的技术手段，就只强调独立的领域层代码，及模型绑定代码。其它的都是一些具体的技巧了。