潘加宇 [初稿写于2018/5/30，最近更新2021/2/17]
功能模块、业务架构、需求分析、用户需求、系统分析、功能设计、详细设计、文档、业务、技术……很多被随口使用的名词，其实是含糊甚至错误的。
到底含糊在哪里，错误在哪里，不仅仅是新手软件开发人员糊涂，许多入行多年的老手也一样。虽然很多老手功成名就，挂着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 电影《武状元苏乞儿》截图
