关于DDD,语言和主流架构

09-08-11 bloodrate
         

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领域版”的东西。

         

banq
2009-08-11 18:14

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

bloodrate
2009-08-11 18:41

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

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

banq
2009-08-11 19:42

每次都要做实体 值对象。

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

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

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

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

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

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

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

xmuzyu
2009-08-11 22:27

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

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

PS:目前我有点厌烦spring了,越来越重了,配置也很麻烦。"简单就是美"在spring上越来越体现不出来了。

[该贴被xmuzyu于2009-08-11 22:28修改过]

3Go 1 2 3 下一页