我还是不怎么明白“领域驱动设计”

12-02-01 javawebkaifa
我是一个初学者,以前一直在写程序,是的,说实话,我发现我没有遇到过一家公司是按照面向对象的建模来进行的(前期分析设计),都是采用数据库建模来进行设计的,我看了很多关于'领域驱动设计"的文章,我发现有些话,说了跟没有说是一回事(我没有别的意思)。我看了下的感觉,就是要对你所开发软件的行业进行非常熟悉的了解,才可以进行'领域驱动设计",我不知道理解对没有,我看到的文章说的软件开发分析方法和设计思路,我觉得非常好,学习中!“领域驱动设计”到底是一个什么玩意???

14
berserk
2012-02-02 11:52
我觉得DDD最有用的地方是以bo来描述业务,如果按照数据库驱动设计、非ddd的方式, 也许很多业务逻辑都分散到了 service、 controller 或者sql中,真正代表业务对象的东西被贫血的model代替了。

这样的后果重领域上看,业务行为无法内聚到相应的业务对象上,比如一个账户业务对象(account)可能有注销,账户欠费通知,转账 的行为。

如果不用ddd,这些行为也许会被分散到n个service里,而没有集中在account上体现。

别人拿着代码,如果不去分析service或者controller,就根本无法从贫血的account上看出 账户究竟能做些什么。

比如,目前我负责的项目就遇到这种问题,大量的业务行为被集中到一个service里,甚至有些不知道该放在哪里的业务行为,也被放到service里了,导致service无比巨大。。可读性,维护性极其差,这就是没有根据领域对象分割职责归属导致的结果,

使用ddd后,因为业务职责清晰划分到对应的bo里,自然就能针对某个BO进行扩展了,而不会影响其他的bo或service,提高了系统的可扩展性

同时,系统可读性大大增强,具有很强的自我描述性,通过读bo,就能知道某个业务对象能做什么,怎么做的。dci更进一步,引入了场景,角色,将实际的业务场景更清晰的显示出来,直接重系统代码上上就能知道系统涉及的各个业务场景,以及在业务场景下,有那些角色参与,这些角色是怎么组合起来实现业务的。

总而言之,我觉得非ddd设计时,系统所有业务逻辑的代码划分是团散沙,只能通过界面操作,controller 来驱动业务,并不能系统架构上真正的体现业务。

ddd的另一大好处是缓存。。但我现在始终无法脱离数据库的影响。

[该贴被berserk于2012-02-02 11:54修改过]

javawebkaifa
2012-02-02 16:52
非常谢谢你的回答:

我是初学者,问的问题很低级,希望不要建议,我最近一直在学习,在观看关于DDD的资料,文档也在看,我看了总是觉得DDD就是你对一个行业的业务理解情况,在这里我说一下我们公司的项目为例:

我们公司现在在开发一套“金融产品”,我进公司半年,我反正觉得我们公司的设计也不说好,也不说差,反正很乱,中国很多软件公司都这样嘛!就拿我这个项目来说,怎么以DDD去理解和分析我们的项目,就拿“领域”来说,要从领域来分析我们的项目,那你肯定一定对我们金融的一切业务很了解,你才敢说领域,我不知道我说得对不,你明白了领域,你才可以从面相对象的设计角度来设计我们的项目,才可以很好的设计我们的业务层。。。。。这样才可以得到所说的DDD的好处和优点。那一句话,就是要明白你开发软件的行业的业务(就是所说的领域)对吗?

你说的,现在项目中,一个service可能有很多代码,这个我给你一样身有感触,有些代码根本不是service的代码,也写在里面,

我还有一个问题,就是关于DDD可以很好的解决需求变更的情况,我觉得不管你怎么样设计(用不用DDD),需求变更都很麻烦,我们公司一样,现在要修改一个功能,改动量很大,很麻烦,完全不灵活,是不是以DDD来进行设计分析(前提是很好的理解金融的业务领域),那样设计出来的项目到时候就很灵活,因为这是建立在DDD领域设计的基础上的,如果是这样,我基本明白,不是这样,我还是很不明白?

banq
2012-02-02 17:30
2012年02月02日 16:52 "@javawebkaifa"的内容
就是要明白你开发软件的行业的业务(就是所说的领域)对吗? ...

老外有句话:As a programmer, it is your job to put yourself out of business. What you do today can be automated tomorrow.作为一个程序员,如果你脱离业务,那么你今天的工作明天就能被自动化实现。

DDD等OO方法技术实际是一种纯自然方式,而使用数据库等有自身约束条件的分析方法,会妨碍对需求的自然分析和设计,比如数据库是表达一种静态二维数据,那么动态的怎么办?只能记录动态的结果数据,而不能表达动态本身。

技术工具自身特点会妨碍对需求的自然分析,不妨碍需求分析的工具最好自身无特点,是一种“无”,但是“无”又比较难以让初学者掌握,你得给他们一个有形的东西他们才容易学,这是世界奥妙之处。

由于DDD等是一种方法思路,而不是有形的产品等,所以,自身不会对需求的变化产生阻碍,需求变化,领域模型设计和代码改一下即可,由于有OO等边界封装,这种修改不会无边界的蔓延扩展开来,造成一发动全身的糟糕局面。而且随着软件规模的复杂,开发和维护工作量总是线性增加,使用其他技术工具就会层现陡峭上升。

[该贴被banq于2012-02-02 17:34修改过]

javawebkaifa
2012-02-03 09:08
谢谢banq的回答:

我现在心里很高兴,我觉得我有那么一点明白领域的意思了,是的,它就是一个思想和无形的对象,它的最能体现(反射)事物特征的设计,是自然的,没有什么限制的分析,才可以发挥后期开发的最大力量。不知道理解对不?

banq
2012-02-03 09:52
2012年02月03日 09:08 "@javawebkaifa"的内容
没有什么限制的分析,才可以发挥后期开发的最大力量。不知道理解对不? ...

是的,自己不会限制分析,无才生有。打个比喻:看电影时,前面有人站起来挡视线,你站起来去劝阻他坐下来,你站起来其实也是挡别人的视线,当你在解决问题时,不要让自己再制造新问题。

javawebkaifa
2012-02-03 16:57
对,是这个问题,我觉得要形成一个重要的领域设计思想的非常不容易的,有领域---抽象模型---代码,这样的几个过程要用领域来分析,在我们抽象模型和代码映射的过程中,可能对于领域来说,这样抽象是非常的好,但是在对应代码实现的时候就不一定能很好的实现,这样代码设计也不符合好的软件项目标准,我非常清楚,领域---抽象模型,但是抽象模型---代码实现,还是有那样一点生硬,不自然,看似没有什么关系,其实关系很紧密。不知道这个过程怎么考虑???

banq
2012-02-03 17:06
2012年02月03日 16:57 "@javawebkaifa"的内容
抽象模型---代码实现 ...

这就需要涉及到其他更细致的方法,比如DCI或事件等,推荐你读一下:机器人分析设计案例,这是我以机器人这个业务为案例,从分析设计直至代码实现过程,可帮助你思考。

道友关于DCI的理解

代码实现时另外一个主要考虑就是性能,见这个讨论:高并发设计

[该贴被banq于2012-02-06 09:20修改过]

niva
2012-03-12 22:19
就算不使用领域驱动设计,就算不使用OO,你也应该对你的业务有清晰的认识啊,不然你怎么保证你写出的程序是正确的?是符合用户需求的?

恰恰相反,领域驱动设计反而适用于对业务并不熟悉的情况,通过逐步重构,逐步精华,来“挖掘”出逻辑。

猜你喜欢