关于DDD，语言和主流架构

Evans说过：虽然DDD是一个不合具体语言绑定的设计思路，并没有强求要什么语言实现，但是DDD确实依赖于语言和架构支持，比如用过程式语言再强大的设计者也很难将DDD操作起来，所以DDD麻烦之处也在于此——某种程度依靠于语言和架构。
在之前banq给的Evans在sourceforge上的开源例子（物流系统）中，Evans使用了Spring MVC，Spring,Hibernate以及HSQLDB实现了他的DDD Sample，是不是也含沙射影说明了现今主流框架中，Spring还是实现DDD的最合适者？？现在越来越多人转向Rails，认为Spring太多的配置文件过于繁冗，但是站在一个DDD忠实拥簇的角度上，拿着DDD书中那么多概念默想“什么框架才能支持聚合，支持仓库，支持实体和值对象，支持Services，支持Facade，支持对象构建与使用分离。。。。才能让我很好的实践DDD”，是不是回过头来还是认为Spring+Hibernate不可取代的呢？
我听有人说过：现在没有任何一个ORM架构能完全支撑起Evans所说的Entity和Value object，但是Hibernate已经比较接近。
现在我需要大家告诉我一个架构集合，到底什么架构组合才能最完美的实现DDD中的所有概念？或者压根还没有这样的组合出现，还需要造轮子的人来专门针对DDD制造诸如“Spring领域版”的东西。

DDD其实是一种方法，就是架构和模型之间粘合的方法。

>DDD其实是一种方法，就是架构和模型之间粘合的方法。

但是总不能每次实现Entity,Value Object,仓库，聚合都重新自己创建吧，总需要一些架构支持你实现这些吧

每次都要做实体值对象。
就是有一个框架或标准，有实体接口或值对象，让你每次实现继承一下，也没有意思。

每个项目的实体值对象都不一样，建模的水平高低就是看谁能准确地区分实体和值对象。就象四色原型一样，有四个颜色，每次都要根据需求向这四个颜色中套。

针对具体行业，可以有一些架构支持，比如针对电信营运行业的NGOSS，企业管理的ERP，因为领域范围缩小了，所以可以形成一些架构支持。

而DDD是一个跨领域的建模方法，所以，很难设计出一些实体值对象模板。

我在设计Jdon框架时，也只是立足实体对象一定是内存中的对象，必须有一个生存空间，引入@Model，实际就是为实体对象盖个房子，但是我自认为这比Spring Hibernate多少要进一步，有一个方向引导。

而你使用Spring + Hibernate，如果不知道DDD，完全可以开发出基于数据库的应用，为实体对象开辟的缓存也只是Hibernate的二级缓存，而Hibernate属于持久层，这就形成一个悖论：作为业务层的核心实体对象却住到了持久层那里去，安家和活动场所搞错了。

[该贴被banq于2009-08-11 20:09修改过]

我觉得DDD中一个很大的魅力就是让我认识到了聚合的重要性。实体和值对象是一个单一的概念，当它们形成聚合的时候就会有丰富的业务意义，并且聚合同时控制访问。至于工厂，仓库，这些可以认为是一些含有功能性意味的业务对象。所以我觉得DDD重核心的概念还是聚合的概念。

目前我个人觉得jdon框架在DDD方面至少要比sping做的好。jdon引入了model的概念,引入model的同时，必然也就需要model缓存，而这些也是切实jdon所做到的。

PS:目前我有点厌烦spring了，越来越重了，配置也很麻烦。"简单就是美"在spring上越来越体现不出来了。
[该贴被xmuzyu于2009-08-11 22:28修改过]

Demo中用到了Spring,Hibernate，楼主就认为这些框架就是最适合DDD．我觉得楼主是不是有点太主观了呀．
其实你大可以这样认为，作者为了迎合读者的口味才选择这些框架的也未尝不可．是不是．

正如banq所讲，DDD只是一种方法．
[该贴被xinying_ge于2009-08-12 14:50修改过]

>正如banq所讲，DDD只是一种方法．

是这样，但是Evans本人也承认，让他用过程式语言，他也无法实现DDD，DDD这个方法还是需要语言和框架本身支持才能发挥的良好，譬如一个框架让你继承一个基础模板然后继承后实现一段事务脚本执行业务，使用这个框架很难实现领域层和设置实体间的boundry，再譬如DDD中有一个概念叫“实体的重现”就是实体从一种介质（数据库记录）转移到另一种介质（内存对象），这其中就可以设计一个工具来实现之间的转化和确保实体的一致性问题，当然如果要说能不能手动作这些事情，当然可以，DDD毕竟只是一个方法，我想说的是如果选择一个不合适的架构或者压根不考虑架构，那么未来领域模型带来的好处将会埋没在为了迎合DDD而去手工补足框架比匹配之处上。

你的担心是有道理的。但是DDD中也为框架的选择指明了道路，比如必须符合分层架构；可以让框架做对象和数据映射；领域模型在分布式架构中的策略。

所以，从这里看出：DDD不同于以往只讨论建模的方法论，它还是落实到具体实处，它的主要贡献不是提出实体值对象规格等概念，而是将面向需求的模型和架构直至细节代码粘合到一起，落实到实处了。跨越分析和设计以及实现的鸿沟。

领域模型和架构的关系：分析设计的时候领域模型独立于架构，而实现的时候，领域模型和架构粘合，真正运行的时候，领域模型和架构完全统一（是不是类似于EJB中，编程时分离，部署时粘合，运行时真正统一的思想）

> 领域模型和架构的关系：分析设计的时候领域模型独立于架构，而实现的时候，领域模型和架构粘合，真正运行的时候，领域模型和架构完全统一（是不是类似于EJB中，编程时分离，部署时粘合，运行时真正统一的思想）

我觉得这个说的有道理，那就很可能出现这种情况：分析时候做出一个优秀的设计，实现时候发现没有架构能支撑起这样一个设计，此时摆在面前有几条路：
1、学习和发现更多的架构，直到找到一个架构能支撑起这样一个设计为止
2、自制架构满足自己的分析设计需要
3、返回到开始，为了迎合架构而本末倒置的修改设计

采用传统的方式，是组件或者服务驱动贫血对象模型完成逻辑，而采用DDD以后，是充血对象模型驱动组件或者服务来完成业务逻辑，我觉得是思维的转变。采用DDD后，系统中的业务对象是占据主导地位，逻辑围绕对象转。