CTO也糊塗的常用術語（01-03）功能模組、業務架構、用戶需求

2019 年 10 月 6 日
筆記

功能模組、業務架構、需求分析、用戶需求、系統分析、功能設計、詳細設計、文檔、業務、技術……很多被隨口使用的名詞，其實是含糊甚至錯誤的。

到底含糊在哪裡，錯誤在哪裡，不僅僅是新手軟體開發人員糊塗，許多入行多年的老手也一樣。雖然很多老手功成名就，掛著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。一個定時收集資訊的系統，根本不需要和人交互，但需求人員也會說「用戶是怎麼要求的？多長時間收集一次？速度要多快？源格式和目標格式是怎樣的？」此時，「用戶」不是指和所研究系統交互的人，而是系統所服務的目標組織的某個負責和開發團隊介面的人。例如，假設這個系統為某市國稅局服務的，需求人員剛才說的「用戶」可能是國稅局資訊中心的副主任。怎樣稱呼這位副主任才正確，後文再說。