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