如何定義架構(gòu)?應用架構(gòu)的要素有哪些?什么是應用架構(gòu)中的分類思維?開源應用架構(gòu)COLA的作者張建飛介紹他在COLA架構(gòu)設計中的一些思想經(jīng)驗，分享他的應用架構(gòu)之道。

模塊(Module)、組件(Component)、包(Package)，這些概念對于我們技術(shù)同學并不陌生，但并不是所有人都能理解其要義。

深入理解之后，我才發(fā)現(xiàn)，其背后的深意是分類思維。而這種分類也是應用架構(gòu)的核心所在，通過不同粒度、不同層次的分類，把復雜的軟件系統(tǒng)實現(xiàn)控制在可以被理解、被維護的程度。否則，對于動則上100萬行代碼的軟件，人類根本沒有辦法理解和維護。

試想一個極端情況，假如沒有這些概念協(xié)助我們分類，我們把所有業(yè)務邏輯都寫在一個類里面，會是什么樣的結(jié)果呢?我們很多的“非人類”系統(tǒng)，正是因為沒有進行合理的分類造成的。

早期，我不喜歡JavaScript的一個重要原因，正是因為其缺少像Java中package和jar的概念，導致代碼的組織形式比較松散、隨意。這個問題直到ES6、React才得到比較好的解決，在此之前，前端工程師不得不依靠seaJS，requireJS這些框架來做模塊化、組件化的事情。

至此，你可能有疑問，分類有什么魔力?怎么就成了應用架構(gòu)的核心了呢?客官別著急，由我細細道來。

分類的重要性

所謂分類，就是依據(jù)一定的標準對給定的事物進行組別的劃分。我們?nèi)祟愄焐陀蟹诸惖谋灸埽?，當我們觀察下面這張圖的時候。

??

無論是誰，乍一看到上面的六個黑點，都會認為共有兩組墨點，每組三個。造成這種印象的原因主要是，人類大腦會自動將發(fā)現(xiàn)的所有事物以某種持續(xù)組織起來?；旧?，大腦會認為同時發(fā)生的任何事物之間都存在某種關(guān)聯(lián)，并且會將這些事物按某種邏輯模式組織起來。

之所以我們大腦有這樣的本能，是因為人一次能夠理解的思想或概念的數(shù)量是有限的。正如喬治米勒在他的論文《奇妙的數(shù)字7》中提出的。人類大腦的短期記憶無法一次容納7個以上的記憶項目。所以，當信息量過大時，唯有歸類分組才能幫助我們?nèi)ダ斫夂吞幚韱栴}。

其實，自古及今，人類一直在做著歸類/分類，早在春秋時期，《戰(zhàn)國策》中就提出過“物以類聚，人以群分”的概念。

在互聯(lián)網(wǎng)行業(yè)，我們會對客戶進行分類，然后針對不同的客戶進行分層運營，也是這個道理。

平常我們所說的分析和綜合的背后，其實就是分類能力。分析是在一個類里面找差異性，綜合是在不同事物中找聯(lián)系、找共同性，而這個共同性相當于分類的維度。

分類思維的能力，直接體現(xiàn)的就是看透事物本質(zhì)的能力。

應用架構(gòu)中的分類思維

概念定義

在討論架構(gòu)之前，我們先來明確一下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.

在《實現(xiàn)領(lǐng)域驅(qū)動設計》一書中，作者有這樣的描述：

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.

??

通過比較，結(jié)合我自己的認知，我更贊同AngularJS里面的定義，即Module是比Component更大的概念。比如在Maven中，Module是組成Application的第一級層次，而Component的粒度一般比Module要小，多個Component會組成一個Module。

因此，在進一步探討之前，我特意對這些概念做如下定義：

• 應用(Application)：應用系統(tǒng)，有多個Module組成，用方框表示。
• 模塊(Module)：一個Module是有一組Component構(gòu)成，用正方體表示。
• 組件(Component)：表示一個可以獨立提供某方面功能的物件，用UML的組件圖表示。
• 包(Package)：Package相對比較tricky，它是一種組織形式，和粒度不是一個維度的，也就是說，一個Component可以包含多個Package，一個Package也可以包含多個Component。

基于上面的定義，他們的表示法(Notation)是這樣的：

??

應用架構(gòu)的要素

關(guān)于架構(gòu)的定義有很多，我最喜歡，也是最簡潔的定義是：

??

即架構(gòu)是一種結(jié)構(gòu)，是由物件(Components)+ 物件之間的關(guān)系 + 指導原則組成的。

應用架構(gòu)也是如此，從大的層面來說，企業(yè)級應用都逃不過如下圖所示的三層結(jié)構(gòu)，即前端、后端和數(shù)據(jù)庫。

??

對于后端開發(fā)來說，應用層是我們的主戰(zhàn)場，也是整個系統(tǒng)最復雜的部分(當然，前端也不簡單)，所有的業(yè)務邏輯都匯聚在此。所以，對于應用層，我們需要進行進一步拆分，而不僅僅是在這里寫業(yè)務邏輯就完事了。

對應用層的進一步分層，就形成了COLA所提倡的四層結(jié)構(gòu)，對應到Maven中，就是有4個Module，編譯打包之后會有4個Jar。一個典型的應用，其Module呈現(xiàn)出如下的結(jié)構(gòu)：

<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>

當業(yè)務變得復雜時，這種分層結(jié)構(gòu)自然比沒有分層要好。這也是COLA一直致力要去解決的問題——控制復雜度。

從COLA 1.0的事無巨細，到COLA 3.0的化繁為簡。我漸漸明白，COLA作為應用架構(gòu)，其核心不是去提供功能，而是提供基模(Archetype)。

在1.0的時候，COLA提供了Interceptor能力，提供了Event Bus能力，提供了擴展點能力。一個是我認為大家“需要”這些，另一個是感覺NB的框架就應該面面俱到，沒有幾個高級功能都不好意思開源。事實證明，我犯了一個慣性錯誤——過度設計。Interceptor完全可以用AOP替代，內(nèi)部事件和擴展點很少被用到。所以在COLA 3.0的時候，果斷的去掉了這些“雞肋”，只保留了擴展點功能。

回歸到架構(gòu)的本質(zhì)，COLA的核心應該是規(guī)定應用的結(jié)構(gòu)和規(guī)范，即應用架構(gòu)基模(Archetype)。而不是去糾結(jié)那些錦上添花的功能。

升級到COLA 3.1

實際上，這樣的回歸工作，COLA 3.0已經(jīng)做的差不多了。在這次3.1的升級中，除了進一步去除了Event Bus的功能之外，最重要的就是重新規(guī)范了分包策略，和擴充了原來控制層(Controller)的職責。

分包策略調(diào)整

分層是一種在功能維度上的橫向切分，即每一層都有自己的職責。

• Adapter層：路由用戶request + 適配response。
• App層：接收請求，聯(lián)合domain層一起做業(yè)務處理。
• Domain層：領(lǐng)域模型 + 領(lǐng)域能力。
• Infrastructure層：技術(shù)細節(jié)(DB，Search，RPC..) + 防腐(Anti-corruption)。

分層處理沒有問題，只是這種功能劃分，會帶來一個問題，即領(lǐng)域維度的內(nèi)聚性會收到影響。當一個application只負責一個領(lǐng)域的時候沒有問題。然而，當一個application包含多個業(yè)務領(lǐng)域的時候，這種內(nèi)聚性缺失的弊端就比較明顯了。

更好的分包策略是按領(lǐng)域劃分，而不是按功能。因為，領(lǐng)域更內(nèi)聚，功能是為領(lǐng)域服務的，應該歸屬于領(lǐng)域。

然而，不巧的是，在COLA應用架構(gòu)里面，我們要綜合橫向功能維度的劃分，和縱向領(lǐng)域維度的劃分，兩個都很好，兩個都想要。怎么辦?我們可以采用物理劃分和邏輯劃分相結(jié)合的辦法。

橫向上，我們用Module做有層次劃分，屬于物理劃分?？v向上，通過Package來進行邏輯劃分。最后，形成一個如下的結(jié)構(gòu)：

??

按照這個思想去分包，在工程中，Module下的頂層package不再是功能，而是領(lǐng)域：

??

按照領(lǐng)域的分包策略至少會帶來兩個好處：

• 系統(tǒng)的可理解性和可維護性更好，用白話說，就是找東西更好找了。
• 方便以后的拆分，比如下單域(Order)變得越來越復雜，需要拆出去，我們只需要把Order下面的東西遷移到一個新應用就好了。

用Adatper代替Controller

Controller這個名字主要是來自于MVC，因為是MVC，所以自帶了Web應用的烙印。然而，隨著mobile的興起，現(xiàn)在很少有應用僅僅只支持Web端，通常的標配是Web，Mobile，WAP三端都要支持。

在這樣的背景下，狹義的控制層已經(jīng)不能滿足需求了，因為在這一層，不僅僅要做路由轉(zhuǎn)發(fā)，還要做多端適配，類似于六邊形架構(gòu)中的Driving Adapter的角色。鑒于此，我們使用適配層(Adapter)替換掉了Controller，一方面，是為了呼應六邊形架構(gòu)；另一方面，的確也是需要做多端適配。

基于這樣的變化，我重構(gòu)了COLA Archetype，把Adapter作為一個層次凸顯出來。實際上，Infrastructure也是適配器，是對技術(shù)實現(xiàn)的適配(或者叫解耦)，比如，我需要數(shù)據(jù)來幫助構(gòu)造Domain Entity，但是我不care這個數(shù)據(jù)是來自于DB、RPC還是Search，或者說，我可以在這些技術(shù)實現(xiàn)中進行自由切換，而不影響我Domain層和App層的穩(wěn)定性。

改造后的COLA在架構(gòu)風格，模塊、組件以及分包策略上都會有所調(diào)整，具體變化請參考下面兩張圖。

COLA架構(gòu)圖：

??

COLA3.1

COLA組件關(guān)系圖：

??

更多關(guān)于COLA 3.1.0的信息，可以訪問：https://github.com/alibaba/COLA 。

組織架構(gòu)中的分類思維

這么重要的思維能力，其應用肯定不僅僅局限于架構(gòu)設計的范疇。開篇已經(jīng)說過了，分類是我們?nèi)祟惖谋灸埽欠治龊途C合問題的重要手段。

生產(chǎn)關(guān)系決定生產(chǎn)力，好的組織結(jié)構(gòu)會助力業(yè)務發(fā)展，反之，則會拖業(yè)務的后腿。因此，大公司的CEO每年都會花很多時間在組織設計上，這也是為什么，在大廠，每年我們都會看到不小的組織調(diào)整。

看到一篇文章《蘋果公司的組織架構(gòu)是怎樣的》[4]，里面介紹了蘋果成功和其優(yōu)秀的組織架構(gòu)有關(guān)系。如下圖所示，傳統(tǒng)企業(yè)偏向于業(yè)務型組織，而高科技企業(yè)偏向于職能型組織。

??

有沒有感覺蘋果的組織架構(gòu)，和我們的COLA思想是一樣的：)，物理上，按照職能劃分;邏輯上，按照業(yè)務和產(chǎn)品劃分。

蘋果這樣的組織設計，是因為它是技術(shù)和創(chuàng)新驅(qū)動的公司，協(xié)作成本不是最大的問題，缺少專業(yè)性(技術(shù)不行)，缺少創(chuàng)新才是攸關(guān)生死的大問題。所以他寧肯犧牲協(xié)同效率，也要確保專業(yè)性，也就是說，做攝像頭的只做攝像頭，做iOS的只做iOS，技術(shù)leader直接向CEO匯報，可以決定產(chǎn)品的發(fā)展方向。因為他們在這個領(lǐng)域更專業(yè)。

很早以前，史蒂夫·喬布斯就有這樣的觀點：蘋果公司的經(jīng)理們應該是他們管理領(lǐng)域的專家。在 1984 年的一次采訪中，他說：

我們在蘋果經(jīng)歷了那個階段，當時我們出去想，哦，我們要成為一家大公司，讓我們雇傭?qū)I(yè)的管理人員。我們出去雇了一群專業(yè)的管理人員。一點也不管用……他們知道如何管理，但他們在專業(yè)方面什么都不知道。如果你是一個偉大的人，為什么你想為一個你什么都學不到的人工作?你知道什么是有趣的嗎?你知道誰是最好的經(jīng)理嗎?他們是偉大的個人貢獻者，他們從來都不想成為一名管理者，但卻決定自己必須成為，因為沒有其他人能夠出色地完成工作。

說實話，看完這篇文章，我很感慨，一方面是佩服喬布斯的洞見能力，另一方面也為我們這個行業(yè)感到唏噓，業(yè)務技術(shù)也是技術(shù)啊，卻沒有一個像樣的培育發(fā)展技術(shù)的環(huán)境和土壤。

如今，業(yè)務技術(shù)Leader還有多少是專注在技術(shù)上呢，儼然都變成了業(yè)務Leader。如果技術(shù)Leader都變成了純管理者，那么誰去關(guān)心技術(shù)，誰去關(guān)心代碼，誰去關(guān)心工程師的成長呢?

分類學是科學也是藝術(shù)

最后，我還是要中庸一下，分類很重要，但同時也很難，帶有一定的主觀性。就像比爾.布萊森在《萬物簡史》里說的：

分類學有時候被描述成一門科學，有時候被描述成一種藝術(shù)，但實際上那是一個戰(zhàn)場。即使到了今天，那個體系比許多人認為的還要混亂。以描述生物基本結(jié)構(gòu)的門的劃分為例。許多生物學家堅持認為總數(shù)30個門，但有的認為20來個門，而愛德華在《生命的多樣性》一書里提出的數(shù)字高達令人吃驚的89門。

我們觀察事物的視角不同，對問題的認知程度不同，得出來的分類也會不同。就拿COLA來說，直到現(xiàn)在的3.1版本，我個人認為其分層和分包的方式才相對比較合理。然而，很有可能在后期的迭代中，分類方式又會改變。

組織架構(gòu)的分類方式也是一樣，按照業(yè)務和職能劃分，都可以。關(guān)鍵看其分類是否匹配你組織的特性，沒有最好的分類，只有最合適的。

除了本文分享的分類思維，更多的思維能力還可以參看作者的新書：《代碼精進之路：從碼農(nóng)到工匠》。這是一本為專業(yè)程序員而寫的書，主要分為技藝、思想和實踐三個部分，詳細介紹了編程技巧和方法論、抽象能力、分治思想、常見的應用架構(gòu)模式，以及COLA架構(gòu)的設計原理。希望能夠幫助廣大程序員培養(yǎng)良好的編程習慣和思維。

相關(guān)鏈接

[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

【本文為51CTO專欄作者“阿里巴巴官方技術(shù)”原創(chuàng)稿件，轉(zhuǎn)載請聯(lián)系原作者】

??戳這里，看該作者更多好文??