但是总不能每次实现Entity,Value Object,仓库，聚合都重新自己创建吧，总需要一些架构支持你实现这些吧
每个项目的实体值对象都不一样，建模的水平高低就是看谁能准确地区分实体和值对象。就象四色原型一样，有四个颜色，每次都要根据需求向这四个颜色中套。
针对具体行业，可以有一些架构支持，比如针对电信营运行业的NGOSS，企业管理的ERP，因为领域范围缩小了，所以可以形成一些架构支持。
而DDD是一个跨领域的建模方法，所以，很难设计出一些实体 值对象模板。
我在设计Jdon框架时，也只是立足实体对象一定是内存中的对象，必须有一个生存空间，引入@Model，实际就是为实体对象盖个房子，但是我自认为这比Spring Hibernate多少要进一步，有一个方向引导。
而你使用Spring + Hibernate，如果不知道DDD，完全可以开发出基于数据库的应用，为实体对象开辟的缓存也只是Hibernate的二级缓存，而Hibernate属于持久层，这就形成一个悖论：作为业务层的核心实体对象却住到了持久层那里去，安家和活动场所搞错了。
[该贴被banq于2009-08-11 20:09修改过]
目前我个人觉得jdon框架在DDD方面至少要比sping做的好。jdon引入了model的概念,引入model的同时，必然也就需要model缓存，而这些也是切实jdon所做到的。
PS:目前我有点厌烦spring了，越来越重了，配置也很麻烦。"简单就是美"在spring上越来越体现不出来了。
[该贴被xmuzyu于2009-08-11 22:28修改过]
正如banq所讲，DDD只是一种方法．
[该贴被xinying_ge于2009-08-12 14:50修改过]
是这样，但是Evans本人也承认，让他用过程式语言，他也无法实现DDD，DDD这个方法还是需要语言和框架本身支持才能发挥的良好，譬如一个框架让你继承一个基础模板然后继承后实现一段事务脚本执行业务，使用这个框架很难实现领域层和设置实体间的boundry，再譬如DDD中有一个概念叫“实体的重现”就是实体从一种介质（数据库记录）转移到另一种介质（内存对象），这其中就可以设计一个工具来实现之间的转化和确保实体的一致性问题，当然如果要说能不能手动作这些事情，当然可以，DDD毕竟只是一个方法，我想说的是如果选择一个不合适的架构或者压根不考虑架构，那么未来领域模型带来的好处将会埋没在为了迎合DDD而去手工补足框架比匹配之处上。
所以，从这里看出：DDD不同于以往只讨论建模的方法论，它还是落实到具体实处，它的主要贡献不是提出实体 值对象 规格等概念，而是将面向需求的模型和架构直至细节代码粘合到一起，落实到实处了。跨越分析和设计以及实现的鸿沟。
我觉得这个说的有道理，那就很可能出现这种情况：分析时候做出一个优秀的设计，实现时候发现没有架构能支撑起这样一个设计，此时摆在面前有几条路：
1、学习和发现更多的架构，直到找到一个架构能支撑起这样一个设计为止
2、自制架构满足自己的分析设计需要
3、返回到开始，为了迎合架构而本末倒置的修改设计