所在位置:答疑 - 内容   
怎么评价领域驱动设计,它和UML是什么关系
 

最近经常被问到一些关于领域驱动设计问题,分几篇文章逐一回答。

问题一:

现在领域驱动设计很火,老师怎么评价,它和UML是什么关系?

答:

先给出看法:

领域驱动设计是在软件开发分析和设计工作流上提出的一些做法。UML是表达分析和设计的可选表示法。

进一步解释如下。

先重复一遍《软件方法》第1章里的内容。

A-业务建模——描述所研究组织内部各系统(人脑系统、电脑系统……)如何协作,使得组织可以为其他组织提供服务。
B-需求——描述为了改进组织的问题,所研究系统必须具有的表现。
C-分析——提炼为了满足功能需求,所研究系统需要封装的核心域机制。
D-设计——为了满足质量需求和设计约束,核心域机制如何映射到选定非核心域上实现。

以上四个工作流的名称使用了传统术语,也有一定的模糊性(特别是业务建模)。其实我觉得更贴切的名称是组织建模、需求建模、核心域建模、实现。如果您觉得业务建模、需求、分析、设计不好,直呼ABCD或改成阿猪、阿狗、阿鸡、阿鸭也无所谓。

只要是软件开发,针对这些内容的思考都是逃不掉的。

表达方式,可以口头表达,也可以用文本、UML、其他表示法或自造符号来表达。

最开始的面向对象分析设计社群就是从领域建模(C-分析)出发的。Peter Coad、Ed Yourdon、Rebecca Wirfs-Brock等人带来的第一批面向对象分析设计书籍,内容焦点都放在如何用对象思想去剖析一个领域的复杂性。

随着GoF《设计模式》一书的流行,一说起学习面向对象,似乎就变成了学习GoF模式。不少开发人员误以为会背诵设计模式,再喊几句"针对接口编程"、"分离变化"、"SRP"、"OCP"之类的口号,就掌握了面向对象设计技能了。

互联网(包括移动互联网)的兴起带来了这样的系统:系统封装的逻辑很简单,但是(也可以说因此)使用的人非常多。

印度人搞的Hotmail于1996年上线,一年多时间内,用户量逼近1000万(这是二十多年前的1000万),1997年底被微软收购。

一个基于web收发邮件的网站,不用什么"领域建模"也很容易写出来,但写出来也没啥用,因为竞争的决胜点不是软件本身封装的逻辑,而是有没有能力烧钱买服务器、带宽、做广告……。

在这种类型的企业中,软件开发团队采用什么开发方法,是站着、坐着还是倒立着开发,都不是竞争的主要影响因素。这也是"敏捷开发"在此类企业大行其道的原因——既然怎么开发都能搞定,能"敏捷"为啥不"敏捷"。

当表面上的包装普及之后,大家都"互联网"了,"互联网"光环已经不足以成为竞争优势。"互联网公司"逐渐演变成"行业领袖",领域建模(C-分析)的重要性逐渐恢复。

Eric Evans的"Domain-Driven Design: Tackling Complexity in the Heart of Software"(2003)用一个新术语"领域驱动设计"重新提醒人们:还是要聚焦于一个核心域,以它来驱动开发,逐渐形成核心竞争力。这是利润所在的地方,再难也不能逃避。

领域驱动设计涉及的主要是C-分析和D-设计,近年也逐渐开始结合一些A-业务建模和B-需求的内容,这是令人欣喜的。

不过也要警惕出现前些年敏捷推广中以“我是大老粗”为荣、以“反智”为荣的思潮。

有一些人,在对前人积累不了解的情况下,凭着自己的一些朦胧认识,随便抛出新概念忽悠他人,认真一看,那些认识连前人的尾巴都碰不到。

用贴纸把墙糊满,看起来很热闹,但凝固的思考还不如一张序列图或状态机图,而且看过去问题满满:研究对象模糊,抽象级别不一致,逻辑混乱。

如果熟练掌握了用例、类、状态机等建模技能,有几个人乐意再去用粗糙不严谨的方法?

就像上学时一样,如果熟练掌握了高中三角函数的知识,解初中的平面几何题时,有多少人乐意再来搞画辅助线、找全等三角形、相似三角形那一套?



当然,思考方法越深刻,门槛就越高,能掌握的人数就越少。严谨的科学往往不如民科流行。

可是,世界的复杂性,或者说软件的复杂性,自有其规律,并不会因为"大多数人能力低不足以掌握",这个规律就不存在了。

在我看来,下面两种论调可以接受:

(1)我这个人能力比较弱,只能掌握全等三角形、相似三角形的方法。

(2)这个题目比较简单,用全等三角形、相似三角形的方法做足够了,而且这样更方便广大人民群众理解。 (不过,竞争对手不是傻子,市场中哪里有什么"简单题目"!)

不能接受的论调是:

(1)全等三角形、相似三角形的知识比高中三角函数的知识更深刻。

(2)把"全等三角形"改名为"叠合三角形",声称发明了新方法,三角函数过时了。

****以上批评,不局限于国内****