CTO也糊塗的常用術語（01-02）功能模塊、業務架構

• 2019 年 10 月 6 日
• 筆記

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

到底含糊在哪裡，錯誤在哪裡，不僅僅是新手軟件開發人員糊塗，許多入行多年的老手也一樣。雖然很多老手功成名就，掛着CTO、總架構師等研發線的最高頭銜，但是心裏對這些概念也是一團漿糊。

可能有的人會說，不會吧，這些牛人帶團隊做出了成功的系統，怎麼會不清楚呢，只不過表達出來和你的表達不同而已吧？我只能很誠懇地再說一遍：很多「牛人」真的不清楚。當然，搞不清楚不妨礙做出讓公司賺錢的系統，就像有的人不了解人體運行機制憑感覺也活到了一百歲。您也可以說「做出過賺錢的系統就行了唄，管他清楚不清楚呢！」，對對對，您說的都對，但不清楚也還是不清楚。

我先說一下我在《軟件方法》一書中對軟件建模工作流的劃分：

1. 業務建模——描述所研究組織內部各系統（人肉系統、電腦系統……）如何協作，使得組織可以為其他組織提供有價值的服務。

2. 需求——描述為了解決組織的問題，所研究系統必須具有的表現——功能和性能。

3. 分析——提煉為了滿足功能需求，所研究系統需要封裝的核心域機制。

4. 設計——為了滿足質量需求和設計約束，核心域機制如何映射到選定平台上實現。

以上四個工作流的名稱使用了傳統術語，也有一定的模糊性（特別是業務建模）。其實我覺得更貼切的名稱是組織建模、需求建模、核心域建模、實現。如果您覺得業務建模、需求、分析、設計不好，改成阿豬、阿狗、阿雞、阿鴨也無所謂。關鍵是要了解劃分的依據，一個是研究範圍，一個是研究內容。如圖1：

圖1 不同工作流的研究範圍和內容

再說一下核心域和非核心域的概念。一個軟件系統封裝了若干領域的知識，其中一個領域的知識代表了系統的核心競爭力，是系統和其他系統區分的關鍵所在。這個領域稱為"核心域"，其他領域稱為"非核心域"。更通俗的說法是"業務"和"技術"，但使用"核心域"和"非核心域"更嚴謹。核心域不一定是物流、醫療、金融等非計算機領域，也可以是計算機和軟件領域。圖2展示了不同系統的核心域和非核心域概念：

圖2 不同系統的核心域、非核心域概念

好，根據以上的知識，我們來逐一剖析這些術語，可能有好幾十個。

術語01：功能模塊

評價：「功能」屬於模糊術語，「模塊」屬於模糊術語，「功能模塊」屬於錯誤術語。

功能（Function）。當我們說起這個詞的時候，研究對象一般是系統。對於組織，一般說「組織的服務」，對於類，一般說「類的操作」。所以，「功能」屬於「需求」的範疇（功能需求），描述系統作為一個整體為其他系統提供的服務，把其他系統給它的輸入變成其他系統所需要的輸出。

但是，「功能需求」仍然不夠精確。例如，以自助櫃員機（ATM）為研究對象，「取現金」是「功能」，「登錄」也是功能，「計算手續費」也是「功能」，到底「功能」有多大？用例的術語要嚴謹得多。「取現金」是一個用例，「登錄」是用例中的一個回合，「計算手續費」是一個步驟。

模塊（Module）。當我們說起這個詞的時候，研究對象一般是系統。模塊表示系統的組成部分，屬於「分析」和「設計」的範疇。這個詞也是模糊的。這個模塊是一個控件？一個類？若干個類形成的組件？

如果說「功能」和「模塊」是模糊的，那麼「功能模塊」就是錯誤的，這個詞混淆了系統外部和內部的區別，需求和設計的區別。

「功能」是系統對外提供的服務，「模塊」是系統的內部結構。連起來說「功能模塊」，意味着在意識里認為「功能」和「模塊」有直接的映射關係，甚至認為「模塊」是屬於某個「功能」的模塊，是為了完成某個「功能」而存在的。

這樣的認識是錯誤的。如圖3所示，完成某個「功能」需要若干「模塊」的協作，而某個「模塊」也會參與完成若干「功能」，例如可以看出「模塊6」被反覆使用了很多次。如果將「功能」和「模塊」直接映射，系統內部將出現大量冗餘。

圖3 「功能」和「模塊」的映射是多對多的

人體就是一個系統，基本功能有走路、跳躍、吃飯等，但是設計人體結構時，不能從外部直接映射到內部，得到人體由「走路模塊」、「跳躍模塊」、「吃飯模塊」組成。人體的「模塊」是五官四肢和內臟，還有最關鍵的——「大腦」。不管是走路、跳躍還是吃飯或者將來發展出更多的「功能」，都由這些「模塊」協作完成。

那麼，那些經常被稱為「功能模塊」的東西，應該怎麼稱呼合適呢？圖4是百度「功能模塊」得到的排第一位的圖片：

圖4 百度「功能模塊」得到的排第一位的圖片，來自http://www.think58.com/asp/9182.html

從圖4得知，「商品銷售管理系統」有很多功能，其中一部分是給用戶使用的，另一部分是給管理員使用的，所以很多人會說「本系統分為兩大功能模塊——用戶模塊和管理員模塊」，但是這樣的說法在意識里不知不覺犯了從外直接映射內部的錯誤，如圖5。

圖5 不知不覺從外部映射到內部

還是用人舉例。人有很多功能，有一部分功能是為老闆提供的，一部分功能是為老婆提供的，還有一部分功能是為老爸老媽提供的。按照圖4的意思，人可以切割成「老闆模塊」、「老婆模塊」……人體確實可以根據內部的耦合和內聚情況切割成不同層次的「模塊」（細胞→組織→器官→子系統），但是和外面的切割沒有直接的映射關係。為老闆服務也好，為老婆服務也好，沒有強大的血液循環子系統（心臟、血管）和神經系統（腦、脊髓、各種神經）都是搞不定的。

設想食人族把一個人大卸八塊（對，模塊的塊），分贓時會怎麼說？「來，左腿歸你，下水歸我」，還是「走路功能歸你，吃飯功能歸我」？

如果要描述若干功能的集合，更貼切的術語應該是「功能包」，如圖6所示。

圖6 用需求包來表達功能集合

當然，如果您硬要說，老子就喜歡叫「功能模塊」，那也可以，關鍵是要了解我上面說的道理。

術語02：業務架構

評價：「業務」屬於模糊術語，「架構」屬於模糊術語，「業務架構」屬於模糊術語。

業務（Business）。「業務」這個詞在軟件開發團隊中使用得很頻繁，例如「我是一名業務架構師」、「我們要了解業務」等等，但是往往說話的人未必真的理解話中的「業務」具體指什麼。

有時候「業務」指的是內容上的劃分，含義是「核心域」。

例如，一個餐館系統，訂單和菜品的關係屬於「業務知識」，折扣的計算規則屬於「業務規則」，如圖7所示。

圖7 餐館系統需要封裝的「業務」——核心域類圖

此時，和「業務」相對應的就是「技術」了。開發人員假裝謙虛「我是做技術的，業務不太懂唉」，就是這個意思。甚至有的開發人員在潛意識裡是這樣劃分的：

我懂且我感興趣的知識→技術；（我是一名Java程序員，Java編碼是技術）

我懂但不感興趣的知識→業務；（下單、收銀、配送我懂一些，但不感興趣，這些是業務）

我不懂但感興趣的知識→高科技；（我不懂深度學習，但很感興趣，哇塞，高科技）

我不懂且不感興趣的東東→忽悠。（我不懂UML建模，也不感興趣，媽的，忽悠）

有時候「業務」指的是範圍上的劃分，含義是「組織級別」。例如，「業務建模」說的是組織級別的建模、「業務用例」說的是組織為其他組織提供的服務，「業務流程」說的是組織內各個系統之間協作的流程。如圖8，表達了餐館的「業務流程」。

圖8 餐館組織的「業務」流程

此時，和「業務」相對應的就是「系統」了。

架構（Business）。「架構」這個詞被濫用得厲害，已經達到一磚頭砸死十個架構師的地步。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."

軟件業樂於做這樣的事——找一些詞彙，並引申出大量微妙而又互相矛盾的含義。一個最大的受害者就是「架構」。

（待續）