一个现实但貌似没人讨论过的问题，用DDD开发软件，设计书怎么写？

用UML图类图即可，如果你愿意用文字补充也可以。

我画完了UML类图，也在其中融合了若干设计模式，PS，第一次感觉很平顺，很自然的使用了设计模式。
但是我觉得UML类图可能无法让程序员了解充分，尤其是不熟悉设计模式和OO的程序员。
苦于思考对策中，所以想起来问问大家是不是有同样的烦恼。

补充：尤其是一些很细节的UML无法体现的细节，
比如：检索条件，策略切换条件，模板方法等等。
总之就是要非常清楚明白的告诉程序员，代码如何正确的进行填空。
[该贴被pye于2011-05-18 16:07修改过]

大白话，却很精确，经常发言从你的角度分享你的经验。

现在打算用时序图来描述调用关系，状态机来描述状态变化，可以解决一部分的问题。
但是类方法的实现细节还是需要文档的，搞个excel模板来写应该差不多了，呵呵

UML是OO分析设计，但去你整出一个算法流程，让程序员去理解？
另外就是你用AD还是SD来描述诸如“检索条件”，“策略”之类的功能呢？

我认为DDD的目的是为了解决领域专家和开发人员之间的代沟，如果开发人员十分了解这个领域就没必要采用DDD；还有就是DDD过程中，是不关注数据库表设计的，Entity才是DDD中需要，且entity不一定对应着table。

至于开发设计文档，传统的文档中要有数据库设计(概要设计，详细设计),那么DDD开发就会忽略这一环节，并使用领域模型(UML的类图)解释阐述领域问题和解决方法。
entity需要带有方法的，这些方法就可能是你上面描述的“检索条件”，“策略”，而如何把这些方法归纳到哪一个(几个)entity中，这才是关键，否则你的领域模型就是可能是失败的。
关于如何来实现这个方法,也就是算法设计，这个应该是程序流程图（DFD）来描述。

其实，UML是因为统一，所以才会用得多而已，关键是如何让程序员理解你的模型。有时候甚至只用框框画出一定逻辑，然后直接用文字描述。

建议 ,你读下
<面向对象的系统分析> 邵维忠 杨芙清 清华大学出版社
然后结合实际情况使用UML和DDD的设计.
注: 是中国人写, 先读后论.