CTO也糊涂的常用术语（01）

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

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

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

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

1. 业务建模——描述所研究组织内部各系统（人肉系统、电脑系统……）如何协作，使得组织可以为其他组织提供有价值的服务。

2. 需求——描述为了解决组织的问题，所研究系统必须具有的表现——功能和性能。

3. 分析——提炼为了满足功能需求，所研究系统需要封装的核心域机制。

4. 设计——为了满足质量需求和设计约束，核心域机制如何映射到选定平台上实现。

以上四个工作流的名称使用了传统术语，也有一定的模糊性（特别是业务建模）。其实我觉得更贴切的名称是组织建模、需求建模、核心域建模、实现。如果您觉得业务建模、需求、分析、设计不好，改成阿猪、阿狗、阿鸡、阿鸭也无所谓。关键是要了解划分的依据，一个是研究范围，一个是研究内容。如图1：

图1 不同工作流的研究范围和内容

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

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

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

术语01：功能模块

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

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

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

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

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

“功能”是系统对外提供的服务，“模块”是系统的内部结构。连起来说“功能模块”，意味着在意识里认为“功能”和“模块”有直接的映射关系，甚至认为“模块”是属于某个“功能”的模块，是为了完成某个“功能”而存在的。

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

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

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

术语02：业务架构

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

（待续）