2010年04月20日 13:00 "taochenpfj"的内容
我们还是会出现这种混淆的问题 ...
分析的结果最后体现在三张上图:类图(代表结构 主要解决是什么,隐藏细节, 由子系统 模块 包 对象群实体和值对象组成); 协作图(类图中对象是在具体场景功能中如何定位,角色是什么,角色之间如何协作?);顺序图(代表行为协作细节,协作图中具体协作顺序 细节是什么?)。
类图是解决结构问题,协作图和顺序图是解决角色 职责协作问题。DDD只侧重前者类图,你看这本书通篇很少见到顺序图或活动图或协作图,归根到底还是一本以数据结构分析为主的建模方法。不全面的。
只靠DDD是得不到这三张图的,只能得到一张类图,只有类图是不能干活的,因为只说明了“它是什么”,没说明,它“干了些什么”,是“怎么干的”。程序员拿到你的类图还是没法干活。
关于实体的疑惑,也是出于此,这也是DDD叙说不足的,实体中一定是包含可变的重要状态,实体一定有重要的职责,一群对象在一起工作,支持一个大的职责,根实体就代表这个大职责代表。
有些设计如果只是从静态特征去分辨,不能确定的,如果我们从动态职责再去分辨,两条路相辅相成,那么就基本能得到一个肯定结果,所以,只靠DDD中的特征辨识是不够的,职责是一种行为特征,应该特别的加以重视。
不是有那么一句:
面向过程程序=算法+数据
面向对象程序=对象+消息
DDD只解决了“对象”的问题,没有解决他们之间是如何通过消息进行协作的。所以,只是提炼出实体对象是不够,实体的重点不只是状态数据,还有导致这些状态数据变化的行为,这些行为我们要去建模,达成统一语言。
[该贴被banq于2010-04-20 14:05修改过]