應(yīng)用架構(gòu)需要分類思維的原因有哪些

這篇文章主要介紹“應(yīng)用架構(gòu)需要分類思維的原因有哪些”，在日常操作中，相信很多人在應(yīng)用架構(gòu)需要分類思維的原因有哪些問題上存在疑惑，小編查閱了各式資料，整理出簡(jiǎn)單好用的操作方法，希望對(duì)大家解答”應(yīng)用架構(gòu)需要分類思維的原因有哪些”的疑惑有所幫助！接下來(lái)，請(qǐng)跟著小編一起來(lái)學(xué)習(xí)吧！

分類的重要性

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

無(wú)論是誰(shuí)，乍一看到上面的六個(gè)黑點(diǎn)，都會(huì)認(rèn)為共有兩組墨點(diǎn)，每組三個(gè)。造成這種印象的原因主要是，人類大腦會(huì)自動(dòng)將發(fā)現(xiàn)的所有事物以某種持續(xù)組織起來(lái)。基本上，大腦會(huì)認(rèn)為同時(shí)發(fā)生的任何事物之間都存在某種關(guān)聯(lián)，并且會(huì)將這些事物按某種邏輯模式組織起來(lái)。

之所以我們大腦有這樣的本能，是因?yàn)槿艘淮文軌蚶斫獾乃枷牖蚋拍畹臄?shù)量是有限的。正如喬治米勒在他的論文《奇妙的數(shù)字7》中提出的。人類大腦的短期記憶無(wú)法一次容納7個(gè)以上的記憶項(xiàng)目。所以，當(dāng)信息量過(guò)大時(shí)，唯有歸類分組才能幫助我們?nèi)ダ斫夂吞幚韱栴}。

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

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

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

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

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

概念定義

在討論架構(gòu)之前，我們先來(lái)明確一下Module、Component和Package這幾個(gè)概念。

因?yàn)檫@些概念一直以來(lái)存在不小的歧義。通過(guò)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 n o criteria to measure which one is greater than the other. One component can contain list of modules, and one module also can contain many co mponents.

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

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的設(shè)計(jì)文檔[3]中，它對(duì)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.

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

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

• 應(yīng)用（Application）：應(yīng)用系統(tǒng)，有多個(gè)Module組成，用方框表示。

• 模塊（Module）：一個(gè)Module是有一組Component構(gòu)成，用正方體表示。

• 組件（Component）：表示一個(gè)可以獨(dú)立提供某方面功能的物件，用UML的組件圖表示。

• 包（Package)：Package相對(duì)比較tricky，它是一種組織形式，和粒度不是一個(gè)維度的，也就是說(shuō)，一個(gè)Component可以包含多個(gè)Package，一個(gè)Package也可以包含多個(gè)Component。

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

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

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

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

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

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

對(duì)應(yīng)用層的進(jìn)一步分層，就形成了COLA所提倡的四層結(jié)構(gòu)，對(duì)應(yīng)到Maven中，就是有4個(gè)Module，編譯打包之后會(huì)有4個(gè)Jar。一個(gè)典型的應(yīng)用，其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啟動(dòng)-->  </modules>

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

從COLA 1.0的事無(wú)巨細(xì)，到COLA 3.0的化繁為簡(jiǎn)。我漸漸明白，COLA作為應(yīng)用架構(gòu)，其核心不是去提供功能，而是提供基模（Archetype）。

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

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

升級(jí)到COLA 3.1

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

分包策略調(diào)整

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

• Adapter層：路由用戶request + 適配response。

• App層：接收請(qǐng)求，聯(lián)合domain層一起做業(yè)務(wù)處理。

• Domain層：領(lǐng)域模型 + 領(lǐng)域能力。

• Infrastructure層：技術(shù)細(xì)節(jié)（DB，Search，RPC..） + 防腐（Anti-corruption）。

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

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

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

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

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

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

• 系統(tǒng)的可理解性和可維護(hù)性更好，用白話說(shuō)，就是找東西更好找了。

• 方便以后的拆分，比如下單域（Order）變得越來(lái)越復(fù)雜，需要拆出去，我們只需要把Order下面的東西遷移到一個(gè)新應(yīng)用就好了。

用Adatper代替Controller

Controller這個(gè)名字主要是來(lái)自于MVC，因?yàn)槭荕VC，所以自帶了Web應(yīng)用的烙印。然而，隨著mobile的興起，現(xiàn)在很少有應(yīng)用僅僅只支持Web端，通常的標(biāo)配是Web，Mobile，WAP三端都要支持。

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

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

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

COLA架構(gòu)圖：

COLA3.1

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

更多關(guān)于COLA 3.1.0的信息，可以訪問：

https://github.com/alibaba/COLA 。

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

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

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

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

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

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

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

我們?cè)谔O果經(jīng)歷了那個(gè)階段，當(dāng)時(shí)我們出去想，哦，我們要成為一家大公司，讓我們雇傭?qū)I(yè)的管理人員。我們出去雇了一群專業(yè)的管理人員。一點(diǎn)也不管用……他們知道如何管理，但他們?cè)趯I(yè)方面什么都不知道。如果你是一個(gè)偉大的人，為什么你想為一個(gè)你什么都學(xué)不到的人工作？你知道什么是有趣的嗎？你知道誰(shuí)是最好的經(jīng)理嗎？他們是偉大的個(gè)人貢獻(xiàn)者，他們從來(lái)都不想成為一名管理者，但卻決定自己必須成為，因?yàn)闆]有其他人能夠出色地完成工作。

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

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

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

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

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

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

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

到此，關(guān)于“應(yīng)用架構(gòu)需要分類思維的原因有哪些”的學(xué)習(xí)就結(jié)束了，希望能夠解決大家的疑惑。理論與實(shí)踐的搭配能更好的幫助大家學(xué)習(xí)，快去試試吧！若想繼續(xù)學(xué)習(xí)更多相關(guān)知識(shí)，請(qǐng)繼續(xù)關(guān)注億速云網(wǎng)站，小編會(huì)繼續(xù)努力為大家?guī)?lái)更多實(shí)用的文章！