作者 | 張建飛
來源 | 阿裡技術公衆号
子產品（Module）、元件（Component）、包（Package），這些概念對于我們技術同學并不陌生，但并不是所有人都能了解其要義。
深入了解之後，我才發現，其背後的深意是分類思維。而這種分類也是應用架構的核心所在，通過不同粒度、不同層次的分類，把複雜的軟體系統實作控制在可以被了解、被維護的程度。否則，對于動則上100萬行代碼的軟體，人類根本沒有辦法了解和維護。
試想一個極端情況，假如沒有這些概念協助我們分類，我們把所有業務邏輯都寫在一個類裡面，會是什麼樣的結果呢？我們很多的“非人類”系統，正是因為沒有進行合理的分類造成的。
早期，我不喜歡JavaScript的一個重要原因，正是因為其缺少像Java中package和jar的概念，導緻代碼的組織形式比較松散、随意。這個問題直到ES6、React才得到比較好的解決，在此之前，前端工程師不得不依靠seaJS，requireJS這些架構來做子產品化、元件化的事情。
至此，你可能有疑問，分類有什麼魔力？怎麼就成了應用架構的核心了呢？客官别着急，由我細細道來。
分類的重要性
所謂分類，就是依據一定的标準對給定的事物進行組别的劃分。我們人類天生就有分類的本能，例如，當我們觀察下面這張圖的時候。
無論是誰，乍一看到上面的六個黑點，都會認為共有兩組墨點，每組三個。造成這種印象的原因主要是，人類大腦會自動将發現的所有事物以某種持續組織起來。基本上，大腦會認為同時發生的任何事物之間都存在某種關聯，并且會将這些事物按某種邏輯模式組織起來。
之是以我們大腦有這樣的本能，是因為人一次能夠了解的思想或概念的數量是有限的。正如喬治米勒在他的論文《奇妙的數字7》中提出的。人類大腦的短期記憶無法一次容納7個以上的記憶項目。是以，當資訊量過大時，唯有歸類分組才能幫助我們去了解和處理問題。
其實，自古及今，人類一直在做着歸類/分類，早在春秋時期，《戰國策》中就提出過“物以類聚，人以群分”的概念。
在網際網路行業，我們會對客戶進行分類，然後針對不同的客戶進行分層營運，也是這個道理。
平常我們所說的分析和綜合的背後，其實就是分類能力。分析是在一個類裡面找差異性，綜合是在不同僚物中找聯系、找共同性，而這個共同性相當于分類的次元。
分類思維的能力，直接展現的就是看透事物本質的能力。
應用架構中的分類思維
概念定義
在讨論架構之前，我們先來明确一下Module、Component和Package這幾個概念。
因為這些概念一直以來存在不小的歧義。通過Stack Overflow上幾十篇詢問這些概念差異的提問，以及五花八門的回答就能可見一斑。
在一篇Stack Overflow的文章[1]中，我們看到這樣的回答：
The terms are similar. I generally think of a "module" as being larger than a "component". A component is a single part, usually relatively small in scope, possibly general-purpose.
然而，另一篇Stack Overflow的文章[2]，卻有着不同的答案：
There is no criteria to measure which one is greater than the other. One component can contain list of modules, and one module also can contain many components.
在《實作領域驅動設計》一書中，作者有這樣的描述：
If you are using Java or C#, you are already familiar with Modules, though you know them by another name. Java calls them packages. C# calls them namespaces.
然而，在AngularJS的設計文檔[3]中，它對Module和Component是這樣定義的：
The module can be considered as a collection of components, Each component can use other components. One of many modules combines up to make an Application.
通過比較，結合我自己的認知，我更贊同AngularJS裡面的定義，即Module是比Component更大的概念。比如在Maven中，Module是組成Application的第一級層次，而Component的粒度一般比Module要小，多個Component會組成一個Module。
是以，在進一步探讨之前，我特意對這些概念做如下定義：
- 應用（Application）：應用系統，有多個Module組成，用方框表示。
- 子產品（Module）：一個Module是有一組Component構成，用正方體表示。
- 元件（Component）：表示一個可以獨立提供某方面功能的物件，用UML的元件圖表示。
- 包（Package)：Package相對比較tricky，它是一種組織形式，和粒度不是一個次元的，也就是說，一個Component可以包含多個Package，一個Package也可以包含多個Component。
基于上面的定義，他們的表示法（Notation）是這樣的：
應用架構的要素
關于架構的定義有很多，我最喜歡，也是最簡潔的定義是：
即架構是一種結構，是由物件（Components）+ 物件之間的關系 + 指導原則組成的。
應用架構也是如此，從大的層面來說，企業級應用都逃不過如下圖所示的三層結構，即前端、後端和資料庫。
對于後端開發來說，應用層是我們的主戰場，也是整個系統最複雜的部分（當然，前端也不簡單），所有的業務邏輯都彙聚在此。是以，對于應用層，我們需要進行進一步拆分，而不僅僅是在這裡寫業務邏輯就完事了。
對應用層的進一步分層，就形成了COLA所提倡的四層結構，對應到Maven中，就是有4個Module，編譯打包之後會有4個Jar。一個典型的應用，其Module呈現出如下的結構：
<modules>
<module>cloudstore-adapter</module> <!--Adapter 層-->
<module>cloudstore-app</module> <!--App 層-->
<module>cloudstore-domain</module> <!--Domain 層-->
<module>cloudstore-infrastructure</module> <!--Infra 層-->
<module>cloudstore-client</module> <!--RPC SDK-->
<module>start</module> <!--SpringBoot啟動-->
</modules> 當業務變得複雜時，這種分層結構自然比沒有分層要好。這也是COLA一直緻力要去解決的問題——控制複雜度。
從COLA 1.0的事無巨細，到COLA 3.0的化繁為簡。我漸漸明白，COLA作為應用架構，其核心不是去提供功能，而是提供基模（Archetype）。
在1.0的時候，COLA提供了Interceptor能力，提供了Event Bus能力，提供了擴充點能力。一個是我認為大家“需要”這些，另一個是感覺NB的架構就應該面面俱到，沒有幾個進階功能都不好意思開源。事實證明，我犯了一個慣性錯誤——過度設計。Interceptor完全可以用AOP替代，内部事件和擴充點很少被用到。是以在COLA 3.0的時候，果斷的去掉了這些“雞肋”，隻保留了擴充點功能。
回歸到架構的本質，COLA的核心應該是規定應用的結構和規範，即應用架構基模（Archetype）。而不是去糾結那些錦上添花的功能。
更新到COLA 3.1
實際上，這樣的回歸工作，COLA 3.0已經做的差不多了。在這次3.1的更新中，除了進一步去除了Event Bus的功能之外，最重要的就是重新規範了分包政策，和擴充了原來控制層（Controller）的職責。
分包政策調整
分層是一種在功能次元上的橫向切分，即每一層都有自己的職責。
- Adapter層：路由使用者request + 适配response。
- App層：接收請求，聯合domain層一起做業務處理。
- Domain層：領域模型 + 領域能力。
- Infrastructure層：技術細節（DB，Search，RPC..） + 防腐（Anti-corruption）。
分層處理沒有問題，隻是這種功能劃分，會帶來一個問題，即領域次元的内聚性會收到影響。當一個application隻負責一個領域的時候沒有問題。然而，當一個application包含多個業務領域的時候，這種内聚性缺失的弊端就比較明顯了。
更好的分包政策是按領域劃分，而不是按功能。因為，領域更内聚，功能是為領域服務的，應該歸屬于領域。
然而，不巧的是，在COLA應用架構裡面，我們要綜合橫向功能次元的劃分，和縱向領域次元的劃分，兩個都很好，兩個都想要。怎麼辦？我們可以采用實體劃分和邏輯劃分相結合的辦法。
橫向上，我們用Module做有層次劃分，屬于實體劃分。縱向上，通過Package來進行邏輯劃分。最後，形成一個如下的結構：
按照這個思想去分包，在工程中，Module下的頂層package不再是功能，而是領域：
按照領域的分包政策至少會帶來兩個好處：
- 系統的可了解性和可維護性更好，用白話說，就是找東西更好找了。
- 友善以後的拆分，比如下單域（Order）變得越來越複雜，需要拆出去，我們隻需要把Order下面的東西遷移到一個新應用就好了。
用Adatper代替Controller
Controller這個名字主要是來自于MVC，因為是MVC，是以自帶了Web應用的烙印。然而，随着mobile的興起，現在很少有應用僅僅隻支援Web端，通常的标配是Web，Mobile，WAP三端都要支援。
在這樣的背景下，狹義的控制層已經不能滿足需求了，因為在這一層，不僅僅要做路由轉發，還要做多端适配，類似于六邊形架構中的Driving Adapter的角色。鑒于此，我們使用适配層（Adapter）替換掉了Controller，一方面，是為了呼應六邊形架構；另一方面，的确也是需要做多端适配。
基于這樣的變化，我重構了COLA Archetype，把Adapter作為一個層次凸顯出來。實際上，Infrastructure也是擴充卡，是對技術實作的适配（或者叫解耦），比如，我需要資料來幫助構造Domain Entity，但是我不care這個資料是來自于DB、RPC還是Search，或者說，我可以在這些技術實作中進行自由切換，而不影響我Domain層和App層的穩定性。
改造後的COLA在架構風格，子產品、元件以及分包政策上都會有所調整，具體變化請參考下面兩張圖。
COLA架構圖：
COLA3.1
COLA元件關系圖：
更多關于COLA 3.1.0的資訊，可以通路：
https://github.com/alibaba/COLA。
組織架構中的分類思維
這麼重要的思維能力，其應用肯定不僅僅局限于架構設計的範疇。開篇已經說過了，分類是我們人類的本能，是分析和綜合問題的重要手段。
生産關系決定生産力，好的組織結構會助力業務發展，反之，則會拖業務的後退。是以，大公司的CEO每年都會花很多時間在組織設計上，這也是為什麼，在大廠，每年我們都會看到不小的組織調整。
看到一篇文章《蘋果公司的組織架構是怎樣的》[4]，裡面介紹了蘋果成功和其優秀的組織架構有關系。如下圖所示，傳統企業偏向于業務型組織，而高科技企業偏向于職能型組織。
有沒有感覺蘋果的組織架構，和我們的COLA思想是一樣的：），實體上，按照職能劃分；邏輯上，按照業務和産品劃分。
蘋果這樣的組織設計，是因為它是技術和創新驅動的公司，協作成本不是最大的問題，缺少專業性（技術不行），缺少創新才是攸關生死的大問題。是以他甯肯犧牲協同效率，也要確定專業性，也就是說，做攝像頭的隻做攝像頭，做iOS的隻做iOS，技術leader直接向CEO彙報，可以決定産品的發展方向。因為他們在這個領域更專業。
很早以前，史蒂夫·喬布斯就有這樣的觀點：蘋果公司的經理們應該是他們管理領域的專家。在 1984 年的一次采訪中，他說：
我們在蘋果經曆了那個階段，當時我們出去想，哦，我們要成為一家大公司，讓我們雇傭專業的管理人員。我們出去雇了一群專業的管理人員。一點也不管用……他們知道如何管理，但他們在專業方面什麼都不知道。如果你是一個偉大的人，為什麼你想為一個你什麼都學不到的人工作？你知道什麼是有趣的嗎？你知道誰是最好的經理嗎？他們是偉大的個人貢獻者，他們從來都不想成為一名管理者，但卻決定自己必須成為，因為沒有其他人能夠出色地完成工作。
說實話，看完這篇文章，我很感慨，一方面是佩服喬布斯的洞見能力，另一方面也為我們這個行業感到唏噓，業務技術也是技術啊，卻沒有一個像樣的培育發展技術的環境和土壤。
如今，業務技術Leader還有多少是專注在技術上呢，俨然都變成了業務Leader。如果技術Leader都變成了純管理者，那麼誰去關心技術，誰去關心代碼，誰去關心工程師的成長呢？
分類學是科學也是藝術
最後，我還是要中庸一下，分類很重要，但同時也很難，帶有一定的主觀性。就像比爾.布萊森在《萬物簡史》裡說的：
分類學有時候被描述成一門科學，有時候被描述成一種藝術，但實際上那是一個戰場。即使到了今天，那個體系比許多人認為的還要混亂。以描述生物基本結構的門的劃分為例。許多生物學家堅持認為總數30個門，但有的認為20來個門，而愛德華在《生命的多樣性》一書裡提出的數字高達令人吃驚的89門。
我們觀察事物的視角不同，對問題的認知程度不同，得出來的分類也會不同。就拿COLA來說，直到現在的3.1版本，我個人認為其分層和分包的方式才相對比較合理。然而，很有可能在後期的疊代中，分類方式又會改變。
組織架構的分類方式也是一樣，按照業務和職能劃分，都可以。關鍵看其分類是否比對你組織的特性，沒有最好的分類，隻有最合适的。
除了本文分享的分類思維，更多的思維能力還可以參看作者的新書：《代碼精進之路：從碼農到工匠》。這是一本為專業程式員而寫的書，主要分為技藝、思想和實踐三個部分，詳細介紹了程式設計技巧和方法論、抽象能力、分治思想、常見的應用架構模式，以及COLA架構的設計原理。希望能夠幫助廣大程式員培養良好的程式設計習慣和思維。
相關連結
[1]
https://softwareengineering.stackexchange.com/questions/178927/is-there-a-difference-between-a-component-and-a-module [2] https://stackoverflow.com/questions/2702816/module-vs-component-design [3] https://medium.com/swlh/angular-component-vs-module-b8c7347c604e [4] http://www.techweb.com.cn/cloud/2020-10-27/2808376.shtml