[答疑]怎么评价领域驱动设计，它和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）把"全等三角形"改名为"叠合三角形"，声称发明了新方法，三角函数过时了。

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