DDD引入的几个问题

10-04-20 taochenpfj
我在我们的项目中引入了ddd的分析方式,可能有点粗略,但是我尽量往ddd靠近,有几点迷惑:

1.统一语言:我们掌握需求信息,根据获取的用户需求列表来分析业务;根据我们的经验来抽取统一语言;我们使用统一语言来建模,实现对象之间的关联关系,但是最大问题是,我们确定的这个统一语言是在变化的,尤其是跟遗留系统产生冲突的时候,很多人不适应这种方式。我认为这种分析层次上的重构是相当必要的,但是会受到参与人员的业务和技术水平的影响,我们的参与人员中没有业务代表,只有熟知业务的开发人员,这个是我一直非常担心的。在这种情况下,各位有没有好的建议,如何降低这种需求片面性风险?

2.实体与值对象的区分:值对象,应该是比较好分割,我们只要把握住一点:免疫的,携带信息的无责任对象。那么对应的实体,就让我们现在比较迷惑,到底什么样的对象就应该做实体,到底什么样的实体应该做聚合根?现在的实体,从持久化层这个角度看,都是一个简单的POJO,尽管我们可能把某个对象置为实体,但是它就是作为一个可以持久化的POJO,对于我们关心的实体的特征:有标识的,有生命周期的业务对象。这个概念使得我们更加迷惑,还是不知道如何区分。希望各位高手给点建议。

3.Service的角色问题:

Service到底是用来做什么用的,根据Eric的观点,这个service应该是独立于实体,也就是那些不依附于任何对象(在此应该指实体对象)的方法的集合。既然我们的Entity都变成了POJO了,那么我们这个service就很容易把我们以前的思想(mvc结构中的action-service-dao分层模式)给抽出来了。所以,这个service又该如何界限呢?

4.所幸,我们还可以区分Factory和Repository,不多说了,但是鉴于上面的3个问题,可能这一部分也是存在问题的。

望各位兄台能给些许意见和建议。。。

小弟在此感激不尽!!!!!

              

2
banq
2010-04-20 11:23
个人观点:关键是只是靠DDD是远远不够的。

要实现统一语言,必须有统一的设计分析模式基础,也就是是模式大学毕业的,如果不深刻理解结构型 行为模式 等,很难达成统一语言。

关于Service定位,也是因为只有DDD是不够的,DDD只是侧重分析结构,没有强调行为动作,建议参考这篇文章:

如何从职责和协作中发现丰富对象?

taochenpfj
2010-04-20 13:00
在分析的过程中,加入设计模式是必然的,我们也有引入的

现在就是在分析层面,我们还是会出现这种混淆的问题

感觉ddd的基础分析和重构也有些混淆的原因在里面

banq
2010-04-20 13:53
2010年04月20日 13:00 "taochenpfj"的内容
我们还是会出现这种混淆的问题 ...

分析的结果最后体现在三张上图:类图(代表结构 主要解决是什么,隐藏细节, 由子系统 模块 包 对象群实体和值对象组成); 协作图(类图中对象是在具体场景功能中如何定位,角色是什么,角色之间如何协作?);顺序图(代表行为协作细节,协作图中具体协作顺序 细节是什么?)。

类图是解决结构问题,协作图和顺序图是解决角色 职责协作问题。DDD只侧重前者类图,你看这本书通篇很少见到顺序图或活动图或协作图,归根到底还是一本以数据结构分析为主的建模方法。不全面的。

只靠DDD是得不到这三张图的,只能得到一张类图,只有类图是不能干活的,因为只说明了“它是什么”,没说明,它“干了些什么”,是“怎么干的”。程序员拿到你的类图还是没法干活。

关于实体的疑惑,也是出于此,这也是DDD叙说不足的,实体中一定是包含可变的重要状态,实体一定有重要的职责,一群对象在一起工作,支持一个大的职责,根实体就代表这个大职责代表。

有些设计如果只是从静态特征去分辨,不能确定的,如果我们从动态职责再去分辨,两条路相辅相成,那么就基本能得到一个肯定结果,所以,只靠DDD中的特征辨识是不够的,职责是一种行为特征,应该特别的加以重视。

不是有那么一句:

面向过程程序=算法+数据

面向对象程序=对象+消息

DDD只解决了“对象”的问题,没有解决他们之间是如何通过消息进行协作的。所以,只是提炼出实体对象是不够,实体的重点不只是状态数据,还有导致这些状态数据变化的行为,这些行为我们要去建模,达成统一语言。

[该贴被banq于2010-04-20 14:05修改过]

taochenpfj
2010-04-20 14:07
是的,是的

我看了Eric的ddd后就在考虑,难道uml要退役了???

看了四色模型之后就在想这种对象间的关联关系

现在跟组内在做领域分析的时候,就是直接在纸上建模,直接画出对象间的关系,但是真正的设计关系还是没有uml里面的类图明确,对象之间的调用关系也没有用协作图来实现

听君一些言胜读十年书啊

自己可能有点死读书了,不过其实我还没有完全读完Eric的书,后面关于分析模式方面的一些东西也是比较深奥

猜你喜欢
4Go 1 2 3 4 下一页