EJB的VO只是一个数据对象，这里VO是和具体Java技术无关的建模设计概念。
以前我们使用EJB，常常容易走上过程化编程习惯，围绕数据库编程，对象为数据服务，对象变成数据对象值对象。
在DDD中，实体Bean要为Domain Model服务，EJB2中实体bean非常不方便，需要Model重新写一遍，然后再做一个VO，而在EJB3中，可以完全实现依赖Domain Model，以Domain Model为核心的开发模式了。
翻译一下不知道对不对。业务层按代码包层次划分为 model 和 service
model为上述领域层 表示业务的概念，model的实例为业务状态信息， 业务规则是什么？
service为上述的应用层 表示软件可完成的工作也就是类中的方法，指挥领域对象则代表new 一个model实例或直接由上层传递过来一个model实例，对其操作解决业务问题。保持精练就是代码写好点用最少的优化过的代码解决问题就OK。无业务状态就是应用层的类不要有属性变量，无业务规则同样还不太了解。
而如果按照DDD的最佳方案设计出的应用层设计规则，也就是其中无业务状态规则等。代表了应用层的服务可应用单例模式。就像IOC容器 HiveMind 默认的服务都是单例的。但如果把带有状态属性的bean也定义为一个service-point用hivemind的注入到某服务时 这样会出现问题，不应该把model设置成服务，那model的创建用什么好那？用时 new一个还是有其他更好的选择如工厂模式
说了这么多不好的，也来说点好听的。Domain-Driven Design，是种方法哈，好在哪里，我认为是解决了沟通的问题。我没有理论的高度，只说一个切身体会：需求分析人员将采集的来得需求做成一个个的用例或者是Story，这些用例描述一些典型的行为动作和预期的结果，而开发设计人员对用例的集合进行综合分析产生了对象模型和数据模型。bang所说的阻抗就是这里了，到这个阶段后，需求分析人员与开发设计人员对一些用例有了明显的不同认识，沟通出现了问题，比如从开发设计角度看，一些用例是有共性的，可以抽象统一起来，而需求分析人员认为这是两个功能模块不能混为一谈，是什么造成了这种沟通的不畅呢？我认为是大家失去了可以用于交流的共同语言，Domain Model是这种语言的基础，基于Domain Model建立的活动图（或者其他什么图都好）是语言，有了这些东西，让需求人员与开发人员联系的更为紧密，也能更好的确保软件的质量和开发进度。
还有一点，是我想说的，Domain-Driven Design不能取代OO Design，也不能取代Database Schema Design，Data Model是基本，OO model和Data Model是不同的表现形式，希望有的兄弟不要想歪了。
买股票，看着大盘猛涨就跟着吃进，总这么干不赔才怪。跟风是要不得的，不希望所有中国的兄弟们被洋鬼子和假洋鬼子们忽悠了。
跟风是要不得的，不希望所有中国的兄弟们被洋鬼子和假洋鬼子们忽悠了。”
samepoint兄真是老经验了。本人跟风跟了三年，吃尽了苦头。最近好好重新啃了啃TIJ、Effective Java，这才感觉重新回到了正路。
[该贴被lgx522于2007年05月18日 14:59修改过]
到底是为了什么而D
另外这是搞培训的，得防忽悠~~~。真的希望中国的java社区能够静下心来，引用别人的话（个人觉得确实有些道理的）：
或许真的如朋友笑谈，java 封装和统一了太多东西，导致程序员的智慧无初发挥，只能集中到设计模式上发泄了 :) 而 C++ ，却有无数的方法证明你的聪明。
另一个例子也很恰当：如果在 java 社区，宣布了一向新特性，会使整个社区的开发效率明显提高，即使这个特性会使世界上所有的 java 程序效率损失 10% 。大多数 java 程序员还是会拍手称快。反正 java 在运行效率上的名声已经臭名招著了，大家也不再在乎。而换到 C++ 社区，即使这个新特性只有 0.1% 而不是 0 的性能损失，必然招至一片唾骂声，吵上10年也不可能写进 ISO 标准。在效率问题上，java 程序员更加指望那些为他们写虚拟机的人做出新的发明，然后发布一个报告，谈即新的技术可以使 java 程序运行速度加快即可。
不得不说，C++ 和 java 是在两个层次上的语言。一个从机器模型延续而来，一丝一环紧紧相扣。而 java 语言却从机器层面向上一跃，中间留下一个空挡。阻止程序员去跨越。这使整个社区的人力集中于更高的层面，未尝不是一件好事啊。
个人比较欣赏网易云风的kiss原则，人家可是大牛^_^,赞同 samepoint 的观点
[该贴被tdd于2010-01-05 02:32修改过]
[该贴被tdd于2010-01-05 02:47修改过]