如何在工作中使用DDD

09-10-30 yananay
    

或许你只是一个普通的程序员,对项目没有任何的控制力,而且只能使用公司中成熟的框架程序;

或许你是一个项目管理者,但是这个项目太大了,涉及了好多方面,你无法自己决定一切。

总之,当我们很多人在学习了DDD之后,遇到的最大的困惑就是:到底在什么地方使用它呢?

自己做个小东西玩玩?总觉得不是那么回事。

想在项目中使用,可是自己没有决定的权利,公司不会轻易改变已经稳定的东西。

所以,学习 DDD,第一步就是要学会 使用 DDD 的思想去分析需求--脑袋长在自己脖子上,别人管不着吧?

根据需求,去分析出领域模型,模型之间的关系,等等。分析需求没有规范,没有框架吧?

分析完了,到实现了,也就是编码。我觉得这个时候大家不必苛求太多,如果能自己决定架构,那么就决定;决定不了,就沿用。虽然实现上可能会别扭,不过在分析阶段已经透彻的话,那么你就比别人站在了更高的角度看问题。

别人指的是什么人?就是以数据库为主导思想的人。我相信,使用 DDD 后分析的产物,再去创建数据库结构,一定会更清晰。不过如果你的领导喜欢讨论数据库设计,那么也一起讨论,没准能弥补你的分析。

用一个例子来描述一下这个过程。

例如现在有一个需求:系统中有“用户”这样的人,“用户”能够买“道具”。

分析后,我们会得到这么两个领域模型:用户 和 道具。

那么用户所购买的道具呢?应该是 用户 模型中的 一个部分道具的集合。

所以,从领域模型的角度来看,我们只需要创建两个类:用户 和 道具。

至于用户所购买的道具,应该是 用户类中的一个表示道具集合的变量。

可是,如果从数据库的观点出发,除了 用户 和 道具 的表,还应该有一个 用户购买的道具 的表。所以------如果是使用传统的 表-类 映射的这种框架,我们需要创建三个类:用户 , 道具 , 用户购买的道具。

这确实很让人矛盾--------不过不要在意这样的矛盾,记住:你已经分析清楚了系统的模型关系,如何实现,那不是重要的。即使用 php 来实现,也是一样的道理。

所以,先实现第一步,在分析中使用DDD,至于第二步,第三步,就得看环境了。

    

ITfuture
2009-11-03 19:39

不错 同意LZ的看法。

顺便说下,在编码中能尽量进行优化的地方可以进行适当的优化。包括复用等等。

在编码的过程中不知不觉沿用或套用设计模式,不仅有助于对模式的理解,更有助于实践中的应用。

[该贴被admin于2009-11-03 20:31修改过]

taochenpfj
2009-11-05 09:48

这个问题真是很让人头痛!

我们可以考虑,可以想,但是对于一个项目,那是整个团队的实践,一个人还是非常不够的,尤其是领域实践需要整个团队的理解才能有一个整体的正确思维和方向!

最近在infoQ上看到几篇文章,还有eric evans的那本书,个人感觉ddd的理论并没有脱离以前的分析和架构方式,而且很多东西是建立在以前的一些理论基础之上的,如:分析模式(Martin的)等等,而对于需求的分析也如同敏捷式的分析方式,所有这些基础性的东西没有一个统筹的话,整个团队不甚了解的话,在项目实施的时候就会有一些风险(或许有很大的风险),所以,我一直不敢轻易将ddd推到团队中去!唉。。。。。

自己的学习也是在把那些基础整合到一起来之后再想项目实践,当然一个小项目的思考还是需要的,banq老师提供的dddsample链接开源小项目还是比较有意思的!

banq
2009-11-05 10:10

其实DDD很简单,就象下面图所示:MF所说:只要你心中有对象,一切都那么简单.

[该贴被banq于2009-11-05 10:12修改过]

taochenpfj
2009-11-05 10:58

我们现在就是贫血的领域特别多,感觉上好像用了很多的对象,但是真正的领域对象(或者就是具有生命周期的对象)特别少,多数就是简单的pojo没有真正的业务操作和实现。

而强行引入的Service层又充当了一个中间人的角色,导致了系统框架形成了“充血”的服务层!

现在想来真是有太多独立的业务代码实现了,而这些实现因为脱离了对象的概念,将动作独立化,也使得具体业务实现跟需求脱离了,整个框架变的很“僵硬”,难于修改,难于适应用户需求的频繁变更!

2Go 1 2 下一页