功能模块、业务架构、需求分析、用户需求、系统分析、功能设计、详细设计、文档、业务、技术……很多被随口使用的名词，其实是含糊甚至错误的。

到底含糊在哪里，错误在哪里，不仅仅是新手软件开发人员糊涂，许多入行多年的老手也一样。虽然很多老手功成名就，挂着CTO、总架构师等研发线的最高头衔，但是心里对这些概念也是一团浆糊。

可能有的人会说，不会吧，这些牛人带团队做出了让公司赚钱的系统，怎么会不清楚呢，只不过表达出来和你的表达不同而已吧？我只能很诚恳地再说一遍：很多“牛人”真的不清楚。当然，搞不清楚不妨碍做出赚钱的系统，就像有的人不了解人体运行机制凭感觉也活到了一百岁。您也可以说“做出过赚钱的系统就行了呗，管他清楚不清楚呢！”，对对对，您说的都对，但不清楚也还是不清楚。

何况，有些系统的成功，研发团队并不是主因。参见《互联网公司的很多“建模体会”没有价值》

我先说一下我在《软件方法》一书中对软件开发工作流的划分：

软件开发的一个迭代周期中需要思考四个问题，即四个工作流：

A-业务建模——定位需要改进的目标组织（人群或机构）以及该组织接下来最需要改进的问题。

B-需求——描述为了改进组织的问题，所引入的信息系统必须具有的表现。

C-分析——提炼为了满足功能需求，所引入的信息系统需要封装的核心域机制。

D-设计——考虑质量需求和设计约束，将核心域机制映射到选定非核心域上实现。

如图1。

图1 四个工作流

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

针对这些工作流的思考，其实就是建模。任何一个软件项目，这些思考都是逃不掉的，也就是说，我们一直在建模，只不过很多人习惯于无意识地做，运气时好时坏，速度时快时慢，有的人能够有意识地做，让汗水不白流。

思考的结果，可以用口头表达，也可以用文本、其他表示法或自造符号来表达。用UML来表达，目前是一种不坏的做法。如果用UML表达，推荐的用法如图2。可以看到，工作流D可以不需要用UML表达。

图2 各工作流思考内容和推荐表达

再说一下核心域和非核心域的概念。一个软件系统封装了若干领域的知识，其中一个领域的知识代表了系统的核心竞争力，是系统和其他系统区分的关键所在。这个领域称为"核心域"，其他领域称为"非核心域"。更通俗的说法是"业务"和"技术"，但使用"核心域"和"非核心域"更严谨。核心域不一定是物流、医疗、金融等非计算机领域，也可以是计算机和软件领域。图3展示了不同系统的核心域和非核心域概念：

图3 不同系统的核心域、非核心域概念

好，根据以上的知识，我们来逐一剖析这些术语，可能有好几十个。

术语01：功能模块

评价：“功能”属于模糊术语，“模块”属于模糊术语，“功能模块”属于错误术语。

功能（Function）。当我们说起这个词的时候，研究对象一般是系统。对于组织，一般说“组织的服务”，对于类，一般说“类的操作”。所以，“功能”属于“B-需求”的范畴（功能需求），描述系统作为一个整体为其他系统提供的服务，把其他系统给它的输入变成其他系统所需要的输出。

但是，“功能需求”仍然不够精确。例如，以自助柜员机（ATM）为研究对象，“取现金”是“功能”，“登录”也是功能，“计算手续费”也是“功能”，到底“功能”有多大？用例的术语要严谨得多。“取现金”是一个用例，“登录”是用例中的一个回合，“计算手续费”是一个步骤。

模块（Module）。当我们说起这个词的时候，研究对象一般是系统。模块表示系统的组成部分，属于“C-分析”和“D-设计”的范畴。这个词也是模糊的。这个模块是一个控件？一个类？若干个类形成的组件？

如果说“功能”和“模块”是模糊的，那么“功能模块”就是错误的，这个词混淆了系统外部和内部的区别，需求和设计的区别。

“功能”是系统作为一个整体所需要完成的行为，“模块”是系统的内部结构。连起来说“功能模块”，意味着在意识里认为“功能”和“模块”有直接的映射关系，甚至认为“模块”是属于某个“功能”的模块，是为了完成某个“功能”而存在的。

这样的认识是错误的。如图4所示，完成某个“功能”需要若干“模块”的协作，而某个“模块”也会参与完成若干“功能”，例如可以看出“模块6”被反复使用了很多次。如果将“功能”和“模块”直接映射，系统内部将出现大量冗余。

图4 “功能”和“模块”的映射是多对多的

人体就是一个系统，基本功能有走路、跳跃、吃饭等，但是设计人体结构时，不能从外部直接映射到内部，得到人体由“走路模块”、“跳跃模块”、“吃饭模块”组成。人体的“模块”是五官四肢和内脏，还有最关键的——“大脑”。不管是走路、跳跃还是吃饭或者将来发展出更多的“功能”，都由这些“模块”协作完成。

那么，那些经常被称为“功能模块”的东西，应该怎么称呼合适呢？图5是百度“功能模块”得到的排第一位的图片：

图5 百度“功能模块”得到的排第一位的图片，来自 http://www.think58.com/asp/9182.html ，非UML图

从图5得知，“商品销售管理系统”有很多功能，其中一部分是给用户使用的，另一部分是给管理员使用的，所以很多人会说“本系统分为两大功能模块——用户模块和管理员模块”，但是这样的说法在意识里不知不觉犯了从外直接映射内部的错误，如图6。

图6 错误！不知不觉从外部映射到内部

还是用人举例。人有很多功能，有些是为老板提供的，有些是为老婆提供的，还有些是为老爸老妈提供的。按照图5的意思，人可以划分成“老板模块”、“老婆模块”……，错！人体确实可以划分成不同层次的“模块”（细胞→组织→器官→子系统），但是是根据内部各部件的耦合和内聚情况划分，和外面的划分没有直接的映射关系。

不能说心脏是老板的，手是老婆的。其实，不管在公司996为老板服务，还是在家里为老婆服务，都需要强大的心脏和灵活的双手。模块是大家共享的。

软件之所以复杂，或者说世界之所以复杂，就是因为需求（外）和设计（内）不是一一对应，而是多对多的。不了解这一点的，再怎么说得天花乱坠，都是错的。

有的“领域驱动设计”的文章里说到如何划分组件（当然，改了新词“上下文”、“微服务”……）时，说自己发明了新方法。一看，就是类似于图6，直接从根据外面的用户和功能来划分。碰到这种内容，就不必再往下看了。

如果要描述若干功能的集合，更贴切的术语应该是“功能包”，如图7所示。

图7 用需求包来表达功能集合

当然，如果您硬要说，老子就喜欢叫“功能模块”，那也可以，关键是要了解我上面说的道理。

术语02：业务架构

评价：“业务”属于模糊术语，“架构”属于模糊术语，“业务架构”属于模糊术语。

业务（Business）。“业务”这个词在软件开发团队中使用得很频繁，例如“我是一名业务架构师”、“我们要了解业务”等等，但是往往说话的人未必真的理解话中的“业务”具体指什么。

有时候“业务”指的是内容上的划分，含义是“核心域”。

例如，一个餐馆系统，订单和菜品的关系属于“业务知识”，折扣的计算规则属于“业务规则”，如图8所示。

图8 餐馆系统需要封装的“业务”——核心域类图

此时，和“业务”相对应的就是“技术”了。开发人员假装谦虚“我是做技术的，业务不太懂唉”，就是这个意思。甚至有的开发人员在潜意识里是这样划分的：

我懂且我感兴趣的知识→技术；（我是一名Java程序员，Java编码是技术）

我懂但不感兴趣的知识→业务；（下单、收银、配送我懂一些，但不感兴趣，这些是业务）

我不懂但感兴趣的知识→高科技；（我不懂深度学习，但很感兴趣，哇塞，高科技）

我不懂且不感兴趣的东东→忽悠。（我不懂UML建模，也不感兴趣，妈的，忽悠）

有时候“业务”指的是范围上的划分，含义是“组织级别”。例如，“业务建模”说的是组织级别的建模、“业务用例”说的是组织为其他组织提供的服务，“业务流程”说的是组织内各个系统之间协作的流程。如图9，表达了餐馆的“业务流程”。

图9 餐馆组织的“业务”流程

此时，和“业务”相对应的就是“系统”了。

架构（Architecture）。“架构”这个词被滥用得厉害，已经达到一砖头砸死十个架构师的地步。Martin Fowler曾经在他的书“Patterns of Enterprise Application Architecture”中写道：

The software industry delights in taking words and stretching them into a myriad of subtly contradictory meanings. One of the biggest sufferers is "architecture."

软件业乐于做这样的事——找一些词汇，并引申出大量微妙而又互相矛盾的含义。一个最大的受害者就是“架构”。

维基百科中这样描述“架构”：

软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通讯。在实现阶段，这些抽象组件被细化为实际的组件，比如具体某个类或者对象。

我的归纳：架构是多个系统内部共有的抽象机制。

要点一：内部。系统提供的各种功能，不属于“架构”。要点二：共有。架构是一种复用机制。它独立于单个系统，围绕它可以组装成系统的家族。

图10是现在常提到的一些架构。可以断定，我们会在很多软件系统中发现这样的机制。图10表达的是不同领域（UI、Database、核心域……）之间交互的机制。不管系统的核心域是哪一个（保险、物流、医疗），这样的机制都可以存在。

图10 域之间的架构

图11也是架构，也可以在千万个软件系统中发现这样的机制。相对于图10，图11表达的是某个领域内部各种领域概念的关系。不管将核心域概念映射到哪些非核心域上（Android还是iOS，Vue还是React）得到系统，这样的机制都可以存在。

图11 域内部的架构

太多的开发人员把过多的精力花在“域之间的架构”上，以求得心里安慰，掩盖自己没有能力思考“域内部的架构”的事实。

你给我介绍说你们团队现在用了某高大上的**架构（**可以替换为分层、菱形、五边形、六边形、洋葱型、整洁型……），好啊，我知道了。还有呢？没了？

构思那些**架构是某些平台厂商或者方法学家的工作，我们挑一个适合自己项目的套路用上就行了。有什么问题，可以去请教用这个套路用得好的先行者。

但是，“域内部的架构”，那些核心领域的复杂逻辑，你要是没有办法理清楚，别人是帮不了你的。这才是你的大脑该用的地方！

“设计要应变”，应的什么变，多半是领域逻辑的问题吧？谁没事整天把“域之间的架构”换着玩？整天津津乐道这个干什么？

在一些软件开发大会常可以看到这样的场景：某电子商务网站的架构师上台讲了一通，接着某视频网站的架构师上台也讲了一通，咦，两个演讲内容如此相似？原来，他们讲的都是自己系统中各域之间的机制（类似图 10“域之间的架构”），而不是核心域内部的机制（类似图 11“域内部的架构”）。究其原因也许并非不为，而是不能——开发人员对自己所开发系统的核心域研究太浅。许多“网红程序员 ”在网上谈论的内容大多是某种语言或框架的新特性，少有探讨他当前所开发系统的复杂领域逻辑，也是同样的原因：并非不为，而是不能。

有的“领域驱动设计”文章和课程，所举例子就1-2个领域类，然后就开始讨论Entity、Service、Repository、DTO、六边形架构……不是说这个知识没用，问题是开发团队缺的是这个嘛？

业务架构。根据以上讲述，这个词有两种含义。

含义一：组织的内部机制。此时，“业务”作“组织”解。图9就描述了这样的机制。维基百科采用的就是这种含义，如图12。此时业务架构师应该负责的是“A-业务建模”的工作。

图12 维基百科上关于业务架构的描述

我们再来看一些公司招聘“业务架构师”（Business Architect）的描述，有的岗位要求还比较贴近“A-业务建模”，如图13。

图13 业务架构师岗位描述1，来自拉勾网

也有不知所云的岗位要求，如图14。

图14 业务架构师岗位描述2，来自拉勾网

含义二：系统内部的核心域机制。此时，“业务”作“核心域”解。图11就描述了这样的机制。此时业务架构师应该负责的是“C-分析”的工作。

遗憾的是，在招聘网站上搜不到符合这个含义的“业务架构师”岗位。搜“架构师”可发现其岗位要求覆盖了“C-分析”和“D-设计”。上文已经说过，绝大多数的“架构师”熟悉的是“D-设计”的工作（图10），不擅长“C-分析”的工作（图11）。

术语03：用户需求

评价：“用户”属于模糊术语，“需求”属于明确术语，“用户需求”属于错误术语。

用户（User）。首先，用户默认是人，没有称某个软件系统为用户的——“本系统的另一个用户是第三方支付系统”；其次用户是和所研究系统有交互的人。例如，我正在用Word写这篇文章，我是Word的用户。以上是最常见的理解。

有时“用户”也会用在根本没有人机交互的地方，如图15。一个定时收集信息的系统，根本不需要和人交互，但需求人员也会说“用户是怎么要求的？多长时间收集一次？速度要多快？源格式和目标格式是怎样的？”此时，“用户”不是指和所研究系统交互的人，而是系统所服务的目标组织的某个负责和开发团队接口的人。例如，假设这个系统为某市国税局服务的，需求人员刚才说的“用户”可能是国税局信息中心的副主任。怎样称呼这位副主任才正确，后文再说。

图15 无人参与交互的收集过程

“用户”一词存在的问题：

（1）很多时候我们口中的“用户”是随意推测的。

我们来看图9的餐馆的例子。我们把它搬到图16。假设图16是餐馆的现状，餐馆的老板希望在此现状之上进一步改进。需求人员很容易先入为主，认定上面的人就是新系统的“用户”，然后逐个找这些“用户”调研。

图16 餐馆的现状

这样的先入为主是不对的。也许餐馆老板希望看到的改进如图17所示。从图中可以看到，领位员这个岗位都不需要了，还找他调研个啥。如果连服务员都可以不要，老板可能觉得更爽。

图17 对餐馆的一种改进

（2）“用户”混淆了演员和观众。

我们先来看用例（Use Case）的一些概念。如图18所示，用例把软件系统看作一部电影，演员（Actor，执行者）在台上表演，观众（Stakeholder，涉众）在台下看，观众按照他们的地位排排坐。演员在台上表演什么是由观众的口味决定的，先照顾前排的观众，如果有余力，再照顾后排的观众。

图18 演员（执行者，Actor）在台上表演，观众（涉众，Stakeholder）在台下看

用例使用“执行者”（Actor）和“涉众”（Stakeholder）代替了原来的“用户”，这是一个非常大的突破。“用户”这个词混淆了演员和观众的区别。过去经常说“找用户调研需求”，这是错误的。所谓“用户”，就是上台表演的人类演员。找用户调研，相当于找演员问剧本应该是什么内容，岂不是很荒谬？剧本应该由编剧向观众调研编写出来，然后由各路演员在台上演绎。

演员如果是人类，那么在观众席上也会有一个位置，不过在第几排就不知道了。范冰冰这样的大咖，可能有能力影响剧本的内容，跑龙套的就算了吧。

在台上当“用户”当得越欢的涉众，往往在涉众排行榜上排位越靠后。您想想，整天操作电脑搞得手僵脖子硬的“用户”，有几个是职位高的呢？真正位高权重的涉众，虽然偶尔也会上台表演，但更多时候是坐在台下看戏。建模人员如果过多地关注“用户”，花在重要的前排涉众身上的时间可能就不够了。

像“用户故事”这样的方法在开发一些面向大众的互联网系统时还能应付，因为这类系统的执行者往往属于前排涉众，以上问题就被掩盖了。如果开发涉众较多、利益冲突微妙的系统，应该采用用例这样更严谨的需求技能。例如做一个手机游戏，重点调研玩家这个“用户”是可以的，做一个某单位的柜台系统，也重点调研窗口工作人员（希望干活越少越好），那背后的领导和其他同事就遭殃了。

另外，现在的系统做出来，越来越多的接口不是面向人类的，而是面向另一个软件系统，也就是说没有“用户”。两个电脑系统交互的需求，难道就不用做了，或者可以随便做？非也。那只是相当于上台表演的不是人，是功夫熊猫、变形金刚和喜羊羊灰太狼，但是台下对表演说好说坏的观众依然是人。建立“执行者和系统在台上表演，涉众在台下看表演”的概念，在执行者为非人系统时对捕获需求很有帮助。

（3）“用户”是拒绝深入思考的遮羞布。

即使是演员和前排观众重叠的系统，“用户”也是一个阻拦需求人员深入思考的词汇。许多产品经理把“用户”挂在嘴边，“要从用户的角度思考”，“用户满意的才是好产品”等等，甚至还有“乔布斯不在意用户的意见”等奇谈怪论。问题来了，谁是用户？

一个老头找到PS可乐公司，告诉他们的主管，“我可是你们的忠诚客户啊！我喝过的可乐罐排成线，可以从苹果园排到通州（北京从西到东）。现在我老了，我对你们的可乐下一个版本提出如下要求：第一，我有胃病，下一个版本不要有这么多气；第二，我有糖尿病，下一个版本里面不要有糖。”PS可乐公司的主管很感动，哇，这么棒的顾客，把要求提得那么具体，省下好多我们调研需求的时间，好，下个版本就这么办！

可惜，现实生活中不会有这样的场景。老头老太太可以买可乐喝，甚至可以买给自己的宠物喝，PS可乐公司不会拦着。问题在于，老头老太太提的要求，或者为他们的宠物提的要求（注意用词：是要求，不是需求），PS可乐公司不会放在重要的位置来考虑，因为PS可乐的目标人群是青少年。可惜，很多时候我问需求人员：“可乐卖给谁？”得到的回答大多是“卖给消费者”，“卖给想喝可乐的人”等对做出好卖的可乐没有帮助的、正确而无用的废话。

我在《软件方法》中，用“老大”取代了“用户”。“老大”是一个真实存在的具体的人。定位“老大”的具体方法参见《软件方法》第2章，和Persona方法类似。但是Persona是虚构一个“用户画像”，说白了也是鼓励需求人员逃避深入第一线调研的辛苦，安心闭门造车。例如，为女性做一个产品，建模人员深入第一线调研，面对的调研对象是一个个具体的女性。如果建模人员把调研的精力花在罗玉凤身上，留给林志玲的精力就不多了，所以必须思考罗玉凤更像老大还是林志玲更像老大的问题。相比起来，关在办公室随意捏造一个符合自己要求的“女性”省事多了。如果满足于Persona，归根结底还是在内心里没有认识到深入第一线调研的重要性。

“老大”的头脑是一块块的战场，所研发的系统是一支军队。研发团队的领导是军队指挥官，他负责找到自己的军队最值得投入的战场，指挥军队和敌人厮杀，占领战场，或者防守住敌人的进攻。战局是残酷的。您手上的三万红军下一步应该杀向哪里，可选项其实少之又少，您必须竭尽全力把这个战场找出来。可惜，许多人低估了现实的残酷，意淫自己手里有百万大军，爱杀往哪里就杀往哪里。

图19 和对手在老大的大脑里厮杀

需求（Requirements）。明确术语，不再单独阐述。

用户需求。错误术语。需求指系统对外提供的功能性能，如果要在“需求”前面加一个定语，这个定语是“系统”——“系统的需求”。

系统的需求就像电影的剧本，规定了电影拍出来必须满足的内容，它是平衡了各种观众的口味（先照顾第一排观众，再照顾第二排……）得到的结果。对所有观众、演员来说，剧本就在那里，不会因为某个观众不喜欢其中某个情节而变化，也不会因为暂时还没有找到演员来拍成电影而变化。所以，不存在什么“用户需求”、“设计需求”、“架构需求”、“开发需求”、“编码需求”等东西。需求不是你的、我的、他的，是系统的，是你我他最终达成的关于系统的一份契约。

那么，“用户”后面能跟什么呢？可以跟“要求”。更严谨的术语是“涉众利益”。需求像电影剧本，涉众像电影观众。剧本只有一份，观众却是多种多样，不同观众的欣赏角度和口味不同。鲁迅说过：一部红楼梦，经学家看见《易》，道学家看见淫，才子看见缠绵，革命家看见排满，流言家看见宫闱秘事。

软件系统也是如此。例如一个生产执行管理系统，老大制造部王部长关注的是“缩短从接到市场部订单到交付产品的时间周期”，车间工人更关心“我这个岗位的工作量会不会增加”，库管员可能担心“以后不好搞手脚”。系统的需求首先要照顾王部长的利益，在不损害王部长利益的前提下，还有余力的话再照顾车间工人和库管员。对于实在照顾不到的后排涉众，很多时候只好抱歉了，这个系统可能会损害你的利益。

软件的需求规约相当于电影剧本。电影剧本不是由观众直接提供，而是由编剧根据不同观众的口味编出来的。同样，软件需求不是由涉众直接提供的，而是由需求人员综合不同涉众的利益来决定的。涉众没有资格提供需求。

系统的需求是平衡各种涉众利益得到的，不由单一涉众决定。以ATM机为例，如果需求人员询问ATM机的执行者储户“取款机应该怎么做你觉得最好”，储户回答大实话“最好像我家抽屉一样拉开就拿，喏，把我家里的抽屉拿去做原型”，需求人员显然不能把这个“抽屉”当真，只需要把“抽屉”背后的涉众利益提炼出来——储户希望操作次数尽可能少一些。最终系统的需求有多少尊重了这个利益，就要看储户在涉众排行榜上的排位了。

拿患者和医生类比也可以帮助理解。患者到医院对医生说“我腿疼，可能得了腿癌，我要做放疗”，医生就给他做放疗？显然不是这样，医生只能把患者所说的一切当成素材，按照成熟的套路，该做什么检查就做什么检查，该如何治疗就如何治疗。

很多时候我们想涉众调研时，涉众直接给出解决方案——“我要一个像某某软件那样的！”如果你真的按照他说的做了，他用的时候又不满意了，而且他的其他同事更不满意。然后我们还委屈呢，都是按照当时开会时你说的做的，还有录音为证！

了解到“涉众无资格提供需求，和涉众交流的内容应该聚焦于涉众利益”，可以帮助我们少犯错误。

术语04：文档

评价：“文档”属于模糊术语。

先列出使用“文档”的一些话语：

你们怎么一上手就写代码，连个文档都没有！

你现在在做什么？我在写文档。

代码就是文档。

从以上话语可以看出以下问题：

（1）在许多软件开发人员的大脑里，“文档”的意思就是“代码之外的其他工件”。由于缺乏软件工程方面的基本知识，对之前提到的“A-业务建模”、“B-需求”、“C-分析”、“D-设计”等工作流没有概念，只好把软件开发工作分为“写代码”和“写文档”两部分。（其实，就连什么叫“代码”，很多人也是糊涂的，这一点后面再说。）

（2）软件开发人员一旦把工件简单分割为“代码”和“文档”，还会导致这样的误解：认为“文档”只不过是“代码”的一种比较概要或比较形象的表现形式，不同的“文档”代表着“代码”的不同视图，可以让开发人员从不同的视角观察代码，这样就便于人脑把握代码的复杂性。如图20所示。

图20 误解：文档只是代码的视图

这种误解不只“普通”的开发人员会有。Martin Fowler所著的UML畅销书《UML精粹》，认为UML有三种用法：草稿、蓝图和编程语言，也是仅从编码的角度来说的。从Fowler写作的其他书籍《重构》、《企业应用架构模式》、《分析模式》等可以知道，他的研究工作集中在分析设计工作流，在业务建模和需求方面研究不多。

这样的误解就会导致推论：只要“代码”写得自己“会说话”，那么“代码就是文档”，“文档”就不需要了。本来“文档”就是“代码以外的其他东西”，这么一推，就变成了“代码就是一切”。

（3）把“文档”当作“代码”的视图还会带来下面这种思维颠倒：先拍脑袋实现，然后再从实现反推其他工作流的内容。例如下面的对话：

张三：这个不应该是系统的用例（如果您不理解什么叫“用例”，就先把它理解为“功能”好了）。

李四：是的！我都写好了，运行一下给你看，这个系统确实提供了这个用例。

是否系统的用例应该以“好卖”来判断。权衡涉众利益之后觉得应该有，系统就有，不该有就没有，而不是我写好了代码，所以就应该有。

张三：这两个类关系不应该是泛化，而是关联。

李四：是泛化，不信我打开代码给你看，或者逆向工程转出类图给你看。

是否泛化关系应该以“符合领域内涵”来判断，而不是先写好代码“人是猪的一种”（肯定编译通过），再用写好的代码来证明“人是猪的一种”。

（4）“文档”还意味着它和“代码”使用的可能是不同的工具写出来的。在Visual Studio、Eclipse里面写出来的叫“代码”，在Word、wiki、Visio、EA等等里面写或者画出来的叫“文档”。

正确的理解是：

不同工作流产出的工件之间的区别不在于形式，而在于思考和表达的内容，如图21所示。

图21 建模工作流思考内容

如果清楚了解“区别在于内容”这一点，就知道“我在写文档”这样的话只是表达“我正在用文档编辑工具在工作”，没有其他意义。你在写什么文档？“业务建模”？“需求”？“分析”？“设计”？我不写，我画图难道不可以吗？我不写不画，我用语音清楚地表达出组织的流程，不可以吗？更有意义的说法应该是“我在做业务建模”。如果说“文档”二字可以给您带来不可替代的快感，可以说“我在写业务建模文档”。

内容和形式的组合是灵活的。很流行的“代码就是设计”这句话的意思就是，设计工作流目前推荐的做法是不需要画UML图或者写“设计文档”，直接用源代码来表达设计模型。编码本身就是一种建模工作。计算机运行的是二进制指令，源代码实际上也是“模型”。之所以被称为“源代码”，是因为它是人脑需要编辑的最低形式模型（编辑完这个就好，后面的事情就可以交给计算机了！）。这个最低形式模型随着时代的发展不断变化。

如图21所示，最初的源代码是机器语言。程序员在纸带或卡片上打孔来表达0和1。后来发现这样太累了，于是发明了一些助记符，这就是汇编语言。 今天会有开发人员故意装×，“这些我不太懂唉，我是做底层的，用C编码”，可是C语言却被归类为“高级语言”，因为类似C这样的语言出现的时候， 大多数程序员编辑的是汇编语言，C相对于汇编来说，当然很高级。今天的一名企业应用程序员，最终需要编辑的可能有 HTML、CSS、JavaScript、Java、配置脚本、SQL等，这些就是现在的“源代码”的形式。

图22 “源代码”的发展历程

从图22中的“历史进程”来看，大趋势是人脑要编辑的“源代码”离计算机原来越远，离领域越来越近。至于最终什么样的具体形式能成为下一形式的代表，只好看各种语言的“个人奋斗”了。

同理，如果人脑只需要编辑UML模型就可以实现系统，那么“模型就是源代码”。例如用带有设计级调试和强大代码生成能力的工具IBM Rational Rhapsody开发实时嵌入系统，在配置好和IDE的集成之后，人脑只需要编辑和调试UML模型（主要是类图和状态机图），就可以实现系统，不需要在IDE里敲字符。感兴趣的读者可以自己去看Rhapsody附带的例子。

“代码就是设计”可以，那么“代码就是需求”可以吗？当然也可以。例如，把整个系统看作一个类，那么这个类的操作就是系统的需求，因为它表达的是系统作为整体提供的服务。

我们在使用UML建模的时候，各种建模元素和建模内容也是灵活匹配的。例如，状态机图，可能一看到就想起分析设计，其实也可以用来表达需求。图23把“电视”作为整体来画状态机，表达的就是“电视”的需求。

图23 用状态机图表达电视的需求（读者可以自行思考图中？处应该写什么。看起来一目了然，其实写对不容易。）

当然，不同的内容有推荐的形式。各建模工作流可以选用的建模图形以及推荐用法如前文图2所示。

术语05：过度设计

"过度设计（overdesign）"属于模糊术语。

很多人说"过度设计"的时候，说的根本不是设计问题，而是“需求蔓延（requirements creep）”。

比如，搜索引擎搜“过度设计”，第一页出来的这个文章：

图24 网络上的“过度设计”（本图仅为示意，不代表同意/不同意观点。）

按照图2的软件开发工作流分工，很多平时所说的“过度设计”，说的是B-需求，说的是花精力去做很多【用】不上功能，而不是说C和D，即系统内部怎么构造的，分解成哪些类，还是没有类全是过程，它们之间怎么互相调用的，分了多少层……

类似于“架构”、“设计模式”，“过度设计（overdesign）”一词应该也是来源于建筑。在计算机行业最早是谁使用我就不知道了，但最有名的应该是1975年 Fred Brooks的《人月神话》里“自律—第二系统效应”一节提到的overdesign：

图25 《人月神话》中的“过度设计”

Brooks说的就是工作流B-系统的需求——“使用”，不是说该系统内部如何构造。

即使是看起来真的是说“内部”的设计的，其实有可能还是需求问题，比如，网络上摘的一篇名为《软件开发-什么是过度设计》的文章里举的例子：

图26 《软件开发-什么是过度设计》截图

以上文章以为所说问题是“设计”，其实问题是，考虑了不存在的需求，跟设计过度不过度没什么关系。更何况，要是“支持美元充值、港币充值”这个需求确实存在，图中这个数据库表把各种变化频率不同的概念搅在一个表里，连“设计”都没有，跟“过度设计”还差十万八千里呢。

至于真正的“过度设计”——系统的需求是正确的，但系统内部构造精妙到过分了，呵呵，似乎我见都没见过。

见到的基本上都是伪装成“过度设计”的“没有设计”。架构师没有掌握类图、状态机图等基本的建模手段，领域逻辑都没有能力理清楚，就知道用自己懂的一点粗浅知识来凑工作量，参见《废话迷》。

更糟糕的是，“过度设计”还成为拒绝思考的遮羞布——我害怕自己“过度设计”，所以干脆就不学习设计了，这样就避免了陷入“过度设计”的陷阱。

图27 电影《武状元苏乞儿》截图

---