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

11-05-18 pye
这个问题貌似没人讨论,软件设计思路很好,但是无法体现在纸上的话也是白费,大家有什么看法?

有模板么?

1
banq
2011-05-18 14:19
用UML图类图即可,如果你愿意用文字补充也可以。

pye
2011-05-18 16:03
我画完了UML类图,也在其中融合了若干设计模式,PS,第一次感觉很平顺,很自然的使用了设计模式。

但是我觉得UML类图可能无法让程序员了解充分,尤其是不熟悉设计模式和OO的程序员。

苦于思考对策中,所以想起来问问大家是不是有同样的烦恼。

补充:尤其是一些很细节的UML无法体现的细节,

比如:检索条件,策略切换条件,模板方法等等。

总之就是要非常清楚明白的告诉程序员,代码如何正确的进行填空。

[该贴被pye于2011-05-18 16:07修改过]

banq
2011-05-19 08:58
2011年05月18日 16:03 "@pye"的内容
总之就是要非常清楚明白的告诉程序员,代码如何正确的进行填空。 ...

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

pye
2011-05-19 11:16
现在打算用时序图来描述调用关系,状态机来描述状态变化,可以解决一部分的问题。

但是类方法的实现细节还是需要文档的,搞个excel模板来写应该差不多了,呵呵

tacitame
2011-07-07 00:55
UML是OO分析设计,但去你整出一个算法流程,让程序员去理解?

另外就是你用AD还是SD来描述诸如“检索条件”,“策略”之类的功能呢?

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

至于开发设计文档,传统的文档中要有数据库设计(概要设计,详细设计),那么DDD开发就会忽略这一环节,并使用领域模型(UML的类图)解释阐述领域问题和解决方法。

entity需要带有方法的,这些方法就可能是你上面描述的“检索条件”,“策略”,而如何把这些方法归纳到哪一个(几个)entity中,这才是关键,否则你的领域模型就是可能是失败的。

关于如何来实现这个方法,也就是算法设计,这个应该是程序流程图(DFD)来描述。

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

fjjiaboming
2012-02-19 11:14
建议 ,你读下

<面向对象的系统分析> 邵维忠 杨芙清 清华大学出版社

然后结合实际情况使用UML和DDD的设计.

注: 是中国人写, 先读后论.

猜你喜欢