Spring+Hibernate的使用很容易产生面向数据表的编程，但不能认为它本质上就是。还是使用方式也就是指导思想的问题。打个比喻：同是一把剑，根据武功秘笈练的和普通朴素自己练的效果就完全不一样。Evans DDD是这样一个较好的武功秘笈。
这个问题又类似当初EJB争论，虽然EJB2.0不是很OO，但是如果使用得当，并不会产生传说中那么多缺点，当然Spring/EJB3更进了一步。
话又说回来，Spring+Hibernate使用DDD的平滑性是不如ROR，但是软件不只是由对象化分析设计开发组成，还由对象化组件拼装构成，Java世界这么多年已经发展了大量对象化组件，我们可以将它们作为构件来构建我们软件一部分，这个同样也很重要，特别是对于构建复杂软件更是这样，而Evans DDD的优点就是体现在复杂软件上。所以，我依然认为Java在对付复杂软件上更胜于ROR，Java是平衡的。
>在真正实现时，都移到了DAO或Service里面，而DAO和Service是无状态的，>Domain其实已经不是Domain，而是Entity（所谓贫血模型）。
Evans DDD已经将Service纳入模型概念，领域模型三个形式：实体模型 值对象和服务。无论存在形式如何，业务逻辑需要扎根在领域层（服务也分领域层和应用层）。
另外，我个人观点：不要被所谓贫血模型概念误导，这又是一个没有准确定义的概念，就象当初POJO一样。不是说将所有行为都放入领域模型就是胖模型了，Jive2就采取了胖模型，但是这样结果导致更多耦合和纠缠。
就是采取更优雅的通过AOP织入，我注意到有人开始将save等操作放在模型中，这个我个人认为不妥，save属于对象持久化，属于对象生命周期的管理维护动作，一个对象不能自己对自己生命周期进行管理维护，这其实是很正常日常生活常识。我们人都是由父母给予生命的，不可能自己创建自己，万事万物的生命都不是它自己创建的，或它自己来管理维护。
>难道领域模型只用来做描述、理解、分析业务不能直接映射成代码实现？
根据我的经验和JiveJdon3，基本可以根据Evans DDD来直接映射到代码。比如JiveJdon3中有大量帖子过滤，例如对HTML过滤，对特别关键字过滤等等，这些都属于论坛这个功能业务，所以，应该放在领域层，但是又不能直接在代码形式放入ForumMessage这个模型中，这时就可以通过Decorator等设计模式来巧妙实现。
>从需求分析的领域模型，逐渐过渡到设计模型，一次次迭代，两种模型(类图)很难match。
只能说模型图逐渐复杂细化，设计模型更加细化，是随着我们对需求认识的不断深入的产物，这个不断迭代深入的模型图才应该是唯一的模型图，不存在两种或几种模型图。