功能模块、业务架构、需求分析、用户需求、系统分析、功能设计、详细设计、文档、业务、技术……很多被随口使用的名词，其实是含糊甚至错误的。
到底含糊在哪里，错误在哪里，不仅仅是新手软件开发人员糊涂，许多入行多年的老手也一样。虽然很多老手功成名就，挂着CTO、总架构师等研发线的最高头衔，但是心里对这些概念也是一团浆糊。
可能有的人会说，不会吧，这些牛人带团队做出了成功的系统，怎么会不清楚呢，只不过表达出来和你的表达不同而已吧？我只能很诚恳地再说一遍：很多“牛人”真的不清楚。当然，搞不清楚不妨碍做出让公司赚钱的系统，就像有的人不了解人体运行机制凭感觉也活到了一百岁。您也可以说“做出过赚钱的系统就行了呗，管他清楚不清楚呢！”，对对对，您说的都对，但不清楚也还是不清楚。
我先说一下我在《软件方法》一书中对软件建模工作流的划分：
A-业务建模——描述所研究组织内部各系统（人肉系统、电脑系统……）如何协作，使得组织可以为其他组织提供有价值的服务。
B-需求——描述为了解决组织的问题，所研究系统必须具有的表现——功能和性能。
C-分析——提炼为了满足功能需求，所研究系统需要封装的核心域机制。
D-设计——为了满足质量需求和设计约束，核心域机制如何映射到选定平台上实现。
以上四个工作流的名称使用了传统术语，也有一定的模糊性（特别是业务建模）。其实我觉得更贴切的名称是组织建模、需求建模、核心域建模、实现。如果您觉得业务建模、需求、分析、设计不好，直呼ABCD或改成阿猪、阿狗、阿鸡、阿鸭也无所谓。关键是要了解划分的依据：一个是研究范围，一个是研究内容。如图1：
工作流 | 范围 | 内容 |
A-业务建模 | 所研究组织和其他组织之间 所研究组织内部各系统之间 | 核心域 |
B-需求 | 所研究系统和其他系统之间 | 核心域 |
C-分析 | 所研究系统内部 | 核心域 |
D-设计 | 所研究系统内部 | 非核心域 |
图1 不同工作流的研究范围和内容
再说一下核心域和非核心域的概念。一个软件系统封装了若干领域的知识，其中一个领域的知识代表了系统的核心竞争力，是系统和其他系统区分的关键所在。这个领域称为"核心域"，其他领域称为"非核心域"。更通俗的说法是"业务"和"技术"，但使用"核心域"和"非核心域"更严谨。核心域不一定是物流、医疗、金融等非计算机领域，也可以是计算机和软件领域。图2展示了不同系统的核心域和非核心域概念：
系统 | 核心域概念 | 非核心域概念 |
文档处理器（如Microsoft Word） | 文档、页、行、字…… | CStringArray、CFileDialog、MSXML…… |
电子商务网站（如淘宝网） | 商品、订单、会员…… | </div>、ActionForm、SessionFactory…… |
图2 不同系统的核心域、非核心域概念
好，根据以上的知识，我们来逐一剖析这些术语，可能有好几十个。
术语01：功能模块
评价：“功能”属于模糊术语，“模块”属于模糊术语，“功能模块”属于错误术语。
功能（Function）。当我们说起这个词的时候，研究对象一般是系统。对于组织，一般说“组织的服务”，对于类，一般说“类的操作”。所以，“功能”属于“B-需求”的范畴（功能需求），描述系统作为一个整体为其他系统提供的服务，把其他系统给它的输入变成其他系统所需要的输出。
但是，“功能需求”仍然不够精确。例如，以自助柜员机（ATM）为研究对象，“取现金”是“功能”，“登录”也是功能，“计算手续费”也是“功能”，到底“功能”有多大？用例的术语要严谨得多。“取现金”是一个用例，“登录”是用例中的一个回合，“计算手续费”是一个步骤。
模块（Module）。当我们说起这个词的时候，研究对象一般是系统。模块表示系统的组成部分，属于“C-分析”和“D-设计”的范畴。这个词也是模糊的。这个模块是一个控件？一个类？若干个类形成的组件？
如果说“功能”和“模块”是模糊的，那么“功能模块”就是错误的，这个词混淆了系统外部和内部的区别，需求和设计的区别。
“功能”是系统对外提供的服务，“模块”是系统的内部结构。连起来说“功能模块”，意味着在意识里认为“功能”和“模块”有直接的映射关系，甚至认为“模块”是属于某个“功能”的模块，是为了完成某个“功能”而存在的。
这样的认识是错误的。如图3所示，完成某个“功能”需要若干“模块”的协作，而某个“模块”也会参与完成若干“功能”，例如可以看出“模块6”被反复使用了很多次。如果将“功能”和“模块”直接映射，系统内部将出现大量冗余。
图3 “功能”和“模块”的映射是多对多的
人体就是一个系统，基本功能有走路、跳跃、吃饭等，但是设计人体结构时，不能从外部直接映射到内部，得到人体由“走路模块”、“跳跃模块”、“吃饭模块”组成。人体的“模块”是五官四肢和内脏，还有最关键的——“大脑”。不管是走路、跳跃还是吃饭或者将来发展出更多的“功能”，都由这些“模块”协作完成。
那么，那些经常被称为“功能模块”的东西，应该怎么称呼合适呢？图4是百度“功能模块”得到的排第一位的图片：
图4 百度“功能模块”得到的排第一位的图片，来自http://www.think58.com/asp/9182.html，非UML图
从图4得知，“商品销售管理系统”有很多功能，其中一部分是给用户使用的，另一部分是给管理员使用的，所以很多人会说“本系统分为两大功能模块——用户模块和管理员模块”，但是这样的说法在意识里不知不觉犯了从外直接映射内部的错误，如图5。
图5 不知不觉从外部映射到内部
还是用人举例。人有很多功能，有些是为老板提供的，有些是为老婆提供的，还有些是为老爸老妈提供的。按照图4的意思，人可以切割成“老板模块”、“老婆模块”……人体确实可以根据内部的耦合和内聚情况切割成不同层次的“模块”（细胞→组织→器官→子系统），但是和外面的切割没有直接的映射关系。为老板服务也好，为老婆服务也好，没有强大的血液循环子系统（心脏、血管）和神经系统（脑、脊髓、各种神经）都是搞不定的。
设想食人族把一个人大卸八块（对，模块的块），分赃时会怎么说？“来，左腿归你，下水归我”，还是“走路功能归你，吃饭功能归我”？
如果要描述若干功能的集合，更贴切的术语应该是“功能包”，如图6所示。
图6 用需求包来表达功能集合
当然，如果您硬要说，老子就喜欢叫“功能模块”，那也可以，关键是要了解我上面说的道理。
访问网址http://www.umlchina.com/book/quizall1to8.htm或扫描以下二维码自测你的水平。共108道题，做完后会给出分数。能答对60道就算不错了！
术语02：业务架构
评价：“业务”属于模糊术语，“架构”属于模糊术语，“业务架构”属于模糊术语。
业务（Business）。“业务”这个词在软件开发团队中使用得很频繁，例如“我是一名业务架构师”、“我们要了解业务”等等，但是往往说话的人未必真的理解话中的“业务”具体指什么。
有时候“业务”指的是内容上的划分，含义是“核心域”。
例如，一个餐馆系统，订单和菜品的关系属于“业务知识”，折扣的计算规则属于“业务规则”，如图7所示。
图7 餐馆系统需要封装的“业务”——核心域类图
此时，和“业务”相对应的就是“技术”了。开发人员假装谦虚“我是做技术的，业务不太懂唉”，就是这个意思。甚至有的开发人员在潜意识里是这样划分的：
我懂且我感兴趣的知识→技术；（我是一名Java程序员，Java编码是技术）
我懂但不感兴趣的知识→业务；（下单、收银、配送我懂一些，但不感兴趣，这些是业务）
我不懂但感兴趣的知识→高科技；（我不懂深度学习，但很感兴趣，哇塞，高科技）
我不懂且不感兴趣的东东→忽悠。（我不懂UML建模，也不感兴趣，妈的，忽悠）
有时候“业务”指的是范围上的划分，含义是“组织级别”。例如，“业务建模”说的是组织级别的建模、“业务用例”说的是组织为其他组织提供的服务，“业务流程”说的是组织内各个系统之间协作的流程。如图8，表达了餐馆的“业务流程”。
图8 餐馆组织的“业务”流程
此时，和“业务”相对应的就是“系统”了。
架构（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."
软件业乐于做这样的事——找一些词汇，并引申出大量微妙而又互相矛盾的含义。一个最大的受害者就是“架构”。
维基百科中这样描述“架构”：
软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通讯。在实现阶段，这些抽象组件被细化为实际的组件，比如具体某个类或者对象。
我的归纳：架构是多个系统内部共有的抽象机制。
要点一：内部。系统提供的各种功能，不属于“架构”。要点二：共有。架构是一种复用机制。它独立于单个系统，围绕它可以组装成系统的家族。
图9是现在常提到的一个架构。可以断定，我们会在很多软件系统中发现这样的机制。图9表达的是不同领域（UI、Database、核心域……）之间交互的机制。不管系统的核心域是哪一个（保险、物流、医疗），这样的机制都可以存在。
图9 域之间的架构，来自taimila.com，非UML图
图10也是架构，也可以在千万个软件系统中发现这样的机制。相对于图9，图10表达的是某个领域内部各种领域概念的关系。不管将核心域概念映射到哪些非核心域上（Android还是iOS，Vue还是React）得到系统，这样的机制都可以存在。
图10 域内部的架构
这里再啰嗦几句。在一些软件开发大会常可以看到这样的场景：某电子商务网站的架构师上台讲了一通，接着某视频网站的架构师上台也讲了一通，咦，两个演讲内容如此相似？原来，他们讲的都是自己系统中各域之间的机制（类似图9），而不是核心域内部的机制（类似图10）。究其原因也许并非不为，而是不能——开发人员对自己所开发系统的核心域研究太浅。许多“网红程序员”在网上谈论的内容大多是某种语言或框架的新特性，少有探讨他当前所开发系统的复杂领域逻辑，也是同样的原因：并非不为，而是不能。
业务架构。根据以上讲述，这个词有两种含义。
含义一：组织的内部机制。此时，“业务”作“组织”解。图8就描述了这样的机制。维基百科采用的就是这种含义，如图11。此时业务架构师应该负责的是“A-业务建模”的工作。
图11 维基百科上关于业务架构的描述
我们再来看一些公司招聘“业务架构师”（Business Architect）的描述，有的岗位要求还比较贴近“A-业务建模”，如图12。
图12 业务架构师岗位描述1，来自拉勾网
也有不知所云的岗位要求，如图13。
图13 业务架构师岗位描述2，来自拉勾网
含义二：系统内部的核心域机制。此时，“业务”作“核心域”解。图10就描述了这样的机制。此时业务架构师应该负责的是“C-分析”的工作。
遗憾的是，在招聘网站上搜不到符合这个含义的“业务架构师”岗位。搜“架构师”可发现其岗位要求覆盖了“C-分析”和“D-设计”。上文已经说过，绝大多数的“架构师”熟悉的是“D-设计”的工作（图9），不擅长“C-分析”的工作（图10）。
访问网址http://www.umlchina.com/book/quizall1to8.htm或扫描以下二维码自测你的水平。共108道题，做完后会给出分数。能答对60道就算不错了！
术语03：用户需求
评价：“用户”属于模糊术语，“需求”属于明确术语，“用户需求”属于错误术语。
用户（User）。首先，用户默认是人，没有称某个软件系统为用户的——“本系统的另一个用户是第三方支付系统”；其次用户是和所研究系统有交互的人。例如，我正在用Word写这篇文章，我是Word的用户。以上是最常见的理解。
有时“用户”也会用在根本没有人机交互的地方，如图14。一个定时收集信息的系统，根本不需要和人交互，但需求人员也会说“用户是怎么要求的？多长时间收集一次？速度要多快？源格式和目标格式是怎样的？”此时，“用户”不是指和所研究系统交互的人，而是系统所服务的目标组织的某个负责和开发团队接口的人。例如，假设这个系统为某市国税局服务的，需求人员刚才说的“用户”可能是国税局信息中心的副主任。怎样称呼这位副主任才正确，后文再说。
图14 无人参与交互的收集过程
“用户”一词存在的问题：
（1）很多时候我们口中的“用户”是随意推测的。
我们来看图8的餐馆的例子。我们把它搬到图15。假设图15是餐馆的现状，餐馆的老板希望在此现状之上进一步改进。需求人员很容易先入为主，认定上面的人就是新系统的“用户”，然后逐个找这些“用户”调研。
图15 餐馆的现状业务流程
这样的先入为主是不对的。也许餐馆老板希望看到的改进如图16所示。从图中可以看到，领位员这个岗位都不需要了，还找他调研个啥。如果连服务员都可以不要，老板可能觉得更爽。
图16 对餐馆流程的一种改进
访问网址http://www.umlchina.com/book/quizall1to8.htm或扫描以下二维码自测你的水平。共108道题，做完后会给出分数。能答对60道就算不错了！
（待续）