DDD 你是如此纠结!

15-05-19 tecentID68055
估计2008年就从Jdon里面看到DDD了, 中间也看过很多DDD方面的帖子。 但是至今还是一知半解。 DDD中文名为“领域驱动设计”。看似简单的6个字,

确让很多人彻夜难眠,纠结无比?

今天又看了一遍:领域驱动设计之我见 http://www.jdon.com/39844/10 大家讨论的很激烈也非常精彩。

但是不得不说,对于我来说益出不大。 为什么这么说? 因为它完全给我一种“百家争鸣”的感觉,每个人写的东西都感觉有道理。导致我甚至分不清好与不好。 这也从侧面反映出DDD是多么的复杂,如此简单的业务,都难以统一大家的思想。更加不用说实际开发项目,实际项目比这可复杂多了,而且那还是团队开发,涉及多人!

帖子中对于 借书 这个业务到底放到哪个对象中? 有人说是reader,有人说是 card。 但是我确觉得这个完全无关紧要,以为我隐隐觉得这2个,实际上都代表了一个真正的领域对象。虽然我也不知道这个领域到底叫什么(好像废话)。

然后我又看了:DDD CQRS和Event Sourcing的案例:足球比赛 http://www.jdon.com/44815 这篇帖子。对于里面的建模,大家好像没有任何异议。 都认为他是对的, 是标准的。 我思考了一下,为啥没有异议? 我认为是这个足球比赛这个案列中他没有 类似于 借书 这样的业务。 而且案例名为“足球比赛” ,大家想当然的就将 比赛 抽象成了一个 类。 这样样就导致 "比赛" 这样一个动作,有了归属。 他直接归属于他自己(因为已经抽象成了类)。实时上我们如果将 足球比赛 案例,称之为球队管理,而比赛只是其中一个业务后? 那么比赛这个动作,归属于谁? 或者说图书管理系统案例中。 我们将它叫做"借书,还书管理"。那么还会有reader,card之争吗?

又比如对于银行转账系统中 a给b转账。 看到很多建模都有一个 转账服务, 里面有装转这个方法。 为啥会有个装转服务, 那是因为 转账这个动作, 放到哪个对象里都有点不合适, 而这个业务其实跟 足球比赛中 ab两队比赛却是如此雷同!

写的很乱,求大神解惑!

1
banq
2015-05-20 07:54
楼主恭喜你已经触碰到DDD核心。

luda
2015-05-20 09:10
有一个问题我搞不清楚,这个问题是:整个世界底层的运行景象和运行原理是否真的和计算机底层的运行景象和运行原理是一样的?

如果这个问题的回答最终是“是”的话,就可以像理解现实世界一样去理解计算机世界,像理解计算机世界一样去理解现实世界了。虽然现实世界底层的景象和原理太难描述了,但是计算机世界描述了它。

对现实世界的理解和对计算机世界的理解如果真能打通的话,剩下的就是“从上而下”和“从下而上”了。有时候从现实世界的问题领域出发是从上而下,从计算机的问题领域出发是从下而上,一上一下相遇在中间层组合出一层“体”。

现实的问题世界和计算机的问题世界是互为上下的,比如计算机世界的底层再往下追溯就又跑到了现实物理世界去了。整个世界可能是个环状的东西,对于整体来说无所谓上和下,只是对于局部来说会有上下之分。

我们作为主体,我们是整个世界的局部,对于我们来说位置靠近我们的就是上,位置远离我们的就是下,位置靠近我们的我们处理起来对于我们来说就符合构造定律就节能,位置远离我们的我们处理起来就不节能,但是计算机处理起来可能节能,而计算机能被我们处理,问题要是能被识别为计算机那样的模式,我们就可以像处理了半个多世纪的计算机问题世界那样去处理现实问题世界了,一旦识别出这个分形的模式后结果又变的符合构造定律又节能了。

领域驱动设计大部分时候是从上而下,但如果宇宙真的像计算机世界那样运行的话,由计算机从下而上的去解决问题也可行。

[该贴被luda于2015-05-20 09:27修改过]

brighthas
2015-05-20 21:13
业务对象抽象出来,是DDD核心,名字很重要,代表一个边界。

其他都是落地必须的过程和手段,cqrs是ddd落地框架,这是一个境界问题,多年的沉淀和研究,让人误以为明白的不说明白话。其实不是隐藏,而是真理有时候确实无法说出来。

记得达摩和弟子说:知者不言,言者不知。意思是知道的人,他无法用语言表达境界(真相),所以也就不说了,怕误导,所以都是用隐喻。

ddd伟大之处在于,在更深的境界来说,具有很强的功力,也就是说,可以无限优化,你有多大能力,就能设计出多好的系统核心。

我这么多年的经验告诉我,捷径是没有的,因为功夫多深,是时间和沉淀修出来的。

brighthas
2015-05-20 21:17
下面是我开发的 node/javascript 版 CQRS框架,可以作为参考,javascript所有人都看得懂。结合了 actor / DDD / cqrs ,因为我觉得这三者打散后,从新组合起来的。思想是ddd,采用了cqrs的事件方式,用actor代表聚合根对象。

https://github.com/liangzeng/cqrs

安装方法 npm install cqrs

tecentID68055
2015-05-21 17:07
@banq banq老师您说我摸到核心,但是我感觉自己一片迷惘中。不知道到底如何是正确的DDD建模。想看看jlive源码,但是没找到哪里下载。能发个下载链接吗?

@brighthas 好东西!

但是我DDD没理透, 再好的框架也玩不转啊。

luda
2015-05-22 15:46
2015-05-21 17:07 "@tecentID68055"的内容
核心 ...

2015-05-20 09:10 "@luda"的内容
一上一下相遇在中间层组合出一层“体” ...

有可能DDD是用来连接人那一端的,ddd思想关注人那一端对世界的认知模式,另一端是计算机的运行时。无论什么模式都不是永久的,各种模式都会随着处理问题的那个主体的变化而变得靠近那个主体或远离那个主体。之前我无法按照计算机的模式处理问题,随着自己对计算机原理的补充慢慢发现能够以计算机的模式思考问题了,突然发现方法世界接通了个什么似的,原来离散着的节点慢慢的变得可以被挂接到某棵主树上去了,一旦挂上去结果就是纳入了那个分形的体系中去了,知识被主体纳入内部的体系后这个主体就变了,他再观察之前的问题的角度变的不一样了。每一个主体人之间存在着差别,这些差别导致对同一个问题的观察角度不一样很难统一,如果ddd真的很难被人们一致的去认识的话这可能说明ddd有问题并不是人有问题,这说明这个时候需要修正ddd,后续的CQRS估计就是用来修正前面的成果的吧,这样的修正会一直存在下去,因为人们一直在变化,问题也一直在变化。唯一不用修正的估计就只有古人的那个“道”了,因为它足够抽象足够底层。

tecentID68055
2015-05-22 17:12
@luda

感觉不是DDD有问题, 而是世界太复杂。

对象的规划,对象的粒度,对象的责任,都难以确定。

而且虽然世界是客观的,但是每个人对世界的认识又不样。

非常希望有一个“得道高手”能教我们如何抽取对象,对象责任如何划分。

就比如图书管理系统中, 借书这个业务 到底是哪个对象的责任。为什么?而现在很多高手都是给你一个框架说这是ddd框架,然后你自己去搞吧。这其实对于初学者没有多大意义。 领域驱动设计, 领域如何建模都不知道。

谈什么框架, 谈什么CQRS, Event Sourcing 等等其他别的东西。 而显现建模才是ddd的核心。

所以个人认为在未“得道”之前,还是使用传统数据库模式为好。 不然搞的东西,不伦不类,而且复杂无比,得不偿失。

[该贴被tecentID68055于2015-05-22 17:24修改过]

freebox
2015-05-26 18:44
不能为了使用某项技术或某个模式,从一开始就去做复杂的设计。

我认为应该从具体的工程中去不断地抽象,如果你的代码能很好地干活,你添加一个功能也没那么复杂,那就别管它了。直到你觉得增加一个功能变得复杂了,感觉和某些部分重合了,不断地在复制粘贴了,觉得代码很乱了,这时应该考虑去抽象了。

我认为模式是在具体的场景中形成的,形成后又能应用于同类场景。但不一定从一开始就发现它,可以随着变更需求来慢慢接近它。

猜你喜欢