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

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

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

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

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

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

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

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

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

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

不是有那么一句：

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

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

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

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

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

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

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

听君一些言胜读十年书啊

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