实战DDD(Domain-Driven Design领域驱动设计)

         
banq 06-07-10


现代业务平台架构应该在什么理论指导下?无疑是MDD模型驱动设计和DDD,Eric的DDD是一本具有很大影响力的书籍
http://www.jdon.com/mda/ddd.html

2
neora
2006-07-18 14:13

回复这个帖子前,先扯一点儿其它,谈谈“软件的算法和方法”。

“软件的算法和方法”这个标题很大,有不懂装懂、故意卖弄之嫌。但我要表述的内容很浅显,只是借用了“XX法”这样高深的名词来表达在软件开发过程中,我们所关注的两个明显区分的领域。

算法
记得我在93年学习软件开发的时候主要关注的应该是算法。比如为了实现长方体的旋转,如何用最快的方式实现矩阵变换。这就是算法。教科书里通常都会精解例举若干种排序的代码。这也是算法。同样,采用不同的方式去遍历一个二叉树或“图”也是算法的范畴。那个时候的软件书籍,除了语言类的,绝大多数是这类的。
但是,跟我同龄段的软件从业者z们大都逐渐发现了一个事实:中国软件产业的发展的主流走向了管理软件和业务软件的方向。为早年写下WPS、CCDOS、CCED的精英们立下汗马功劳的精妙绝伦算法研究已经很难派上大的用场。只要你会用VB/PB/Delphi,通过Drag控件和凌乱的逻辑代码就可以实现一套完整的OA、管理信息系统、图书馆管理软件或者财务软件。这其实是中国软件产业的一个悲哀。
我们的专家们说,“中国软件业的前途是管理软件而不是系统软件”。于是我们从流,于是今天我们热衷于讨论的是软件设计的“方法”,“算法”的问题可以通过调用别人的lib去解决。
没错,牛顿也是站在别人的肩膀上的。可是我们同样站在上面望去,看不到我们民族的肩膀。跑题了。转回来。
在算法研究舞台上的缺位,让我们把所有的精力都倾注在了“方法”的研究和讨论上。特别最近3年,由Java开发本身所引出的各种方法层出不穷,引得我们无限追捧。

方法
软件开发/设计方法是一个这个行业最不可缺少的基础。软件工程组织、软件设计模式、软件框架、编程规范、测试驱动开发包括MDD/DDD都应该算是广义上的软件设计方法的范畴。而各个概念专注的领域不同,解决问题的重点也同:
软件工程的各种方法的目标是:组织和管理人员、时间、目标、过程、质量甚至预算。
软件设计模式的目标是:组织和管理程序的跳转逻辑。btw,“跳转逻辑”这个名词不够OO,是过程编程的概念。但任何OO语言走到下面到了编译原理和运算原理一层,就转化成“过程”了。
编程规范的目标是:组织和管理代码、注释、文档和数据资源。
测试驱动开发(TDD)的目标是:组织和管理编码和测试的过程,并最终对软件质量进行控制和管理。
MDD/DDD的目标则是:组织和管理复杂软件实现结构上的分析和设计,以求得一套清晰的指导思想来指引软件设计者在面对大型软件需求的时候,能够进入“万变不离其中”的“自由王国”。

DDD
做为《实战DDD(Domain-Driven Design领域驱动设计)》的跟帖,终于罗嗦到DDD。
我感觉到,无论采用何种方法翻译DDD中的Domain都难以找到一个最合理的汉语词汇来表达DDD的思想。即便现在普遍采用的“领域”一词,也令人感到晦涩。其实我们应该摒弃“望文生意”的方式。也许直接称其为DDD,把“DDD”当成跟Java一样的代号,然后再去理解其中所表达的思想,这样会对学习更有帮助一些。
另外一个重要的认识是:尽管DDD现在很流行,但从前没有DDD(词)的时候,一样可以开发出优秀的软件。在DDD这个词出现之前,许多类似的概念都在软件设计中大量采用了。也许你也用过,但从来没有提炼成一种“方法学”上的理论。Eric E.提炼了这个概念。这个概念必然来自于他的实践。

所谓“领域驱动设计”看样子是目前最难直接理解的概念之一(而且直译过来后跟汉语的语法出入很大)。但如果你能把DDD看成若干中“理论”中的一种,那这个概念就很好接受了。

首先,只要是“理论”,就会有很多流派。每个流派的理论都必然有其可取之处。DDD看似要成为主要流派之一的,那么初学者就可以暂时无条件的去接受它。这也是“站在别人肩膀”上的做法。――不要反驳“无条件”这个词,你不是也无条件接受了牛顿三定律么?
第二,只要是“理论”,初学者就大可不必去深究“为什么是这样”。没有4年5年6年的开发经验,就不要去质疑。否则你的质疑只能拿去印证“无知者无畏”这句话的真理性,或者直接陷入类似《一个“Spring轮子”引发的血案》的血案的血案的血案中去。“理解”本身需要一个过程。经历丰满的程序员在实践过DDD后会感慨:“从前我为什么不这样做!”。软件开发初学者没有从前,必然也无法体会出先苦后甜的感受。
第三,只要是“理论”,总是但方面的。总有站得住脚和站不住脚的地方。“算法”是有其唯一性的,是可以被证明其正确性和极限性(“顶点”)的。而“方法”则不具备唯一性的特质。歪用DDD中的一个词来阐释:某种方法在某些领域(Domain)中是优秀的,而在其它的(Domain)则可能并不合适。因此,DDD也不是放之四海而皆准的真理。

根据常年混帖的经验,必有血气方刚的革命小将会质疑我把DDD称为"理论”的做法。如有反驳的冲动,肯请不要在这里跟我理论。我只是一家之言,谈谈自己的感受罢了。



j10A
2006-07-19 08:07

还是邓小平讲的好,管你白猫黑猫,逮到耗子就算好猫。
一些所谓“先进”不过是某些开发人员偏执的自娱自乐罢了。
过一段时间时机成熟,本人也打算对外发放一些开发框架库,包括web开发框架,数据库开发框架,业务层开发框架以及若干高性能开发程序包。这些东西不想与别人的东西争高低,只是想提供一种相当敏捷、相当高性能而且非常便于维护的开发工具组合。Java是个很优秀的语言,然而在国内外人很多“先进”人士的折腾和怂恿下,开发过程变得异常臃肿而晦涩。java应该反省了,不应该让php,asp等辈找到“开速开发”的口实。

banq
2006-07-24 17:27

>java应该反省了,不应该让php,asp等辈找到“开速开发”的口实。
DDD实际提供这样快速而又灵活的软件开发思路。

快速而又灵活非常重要,过去是快速而不灵活,象PHP等将Html和语言脚本混合在一起的软件系统易于维护和拓展吗?能灵活快速应付变化吗?显然不行。

所以,我们不能单纯看快速,而忘记软件解耦性,DDD是肯定软件分层架构:表现层、业务层(领域层和应用层)以及持久层基础上,提出快速建模方法,DDD认为那种智能UI快速开发是反模式。

为什么用“反模式”来否定它,因为模式是我们做软件基础,就象大家都接受过数学物理的基础教育,因此我们沟通交流就有了最基本的对话平台,如果你不懂模式,就象你没有上过学,如何和你对话呢?正是那句:秀才遇到兵,有理说不清!大家没有沟通对话的基础平台。

这也就是为什么那么多打着快速开发旗帜的工具受那么多人欢迎,因为他们虽然上过软件大学,但是没学过模式,所以,实际就是“小学没有毕业”,和他们讲,这样的工具要不得,就是说不清了,秀才遇到兵了,你说中国软件能不萧条吗?都是伪软件人在上面唱戏!

lhsail
2006-08-29 18:56

这些东西其实很早就使用了,只是没有去总结到理论的高度。
感觉大家老是讨论模型和各种新奇的理论、名词,而很少讨论开发过程中遇到的具体问题和解决方法。也就是说多数人总是在谈论各种“轮子”,而没有讨论如何让这些“轮子”去“转动”。

实际的项目开发中会遇到很多问题。实际的问题不仅在用户的需求,系统的开发维护和扩展更是需要重点考虑的。开发效率、可重用性、可扩展性、可维护性(包括稳定性)这些都是不可或缺的东西。举个例子:在管理系统中,权限系统是最麻烦、可重复性最大的部分之一,怎么没有看到谁在用什么模型来解决这个问题呢。笔者在开发领域混了N年,C++和JAVA都算得是经验丰富得实践者,自己设计、实现过不少架构性的东西(当然还不成体系的),很多模型都用过了,不过不是看书来的,是在解决问题的过程中自然总结而来。分层、解耦、SOA都是实践过程很自然的选择,根本就没有商业炒作的那么玄乎。建议新同志多去研究一下实际项目(开源的多得很),不要迷在各种理论、模式中。很多东西不经过实践是不能深刻理解它得真实意义的。另外很多时候都不是非此即彼的选择,得根据实际情况来决定。还有没有经过大项目的历练,是很难成为架构师的。否则理论再强,也不见得是真正的程序员、架构师,就如那个历史上著名的马谡一样.....

设想一下,如果一个项目不断延续开发好多年而不需要调整架构,能适应各种新需求、新应用环境,如果能做到这样可能就算得是真正得架构师了。

6Go 1 2 3 4 ... 6 下一页