從方法到思惟：什麼是應用邏輯架構的正確姿式？

Blog: https://blog.yilon.top

做者: 阿里技術

地址: https://zhuanlan.51cto.com/art/202004/613905.htm

本文分享阿里資深技術專家六銖的架構方法論，這套方法論中包含了詳細的架構推導邏輯，但願可以幫助你們在工做中從各個粒度、各個層次來作好架構工做。較長，同窗們可先收藏再看。

1、背景

1.1 架構中的問題識別

需求分析，架構實現，(新需求，架構改動)* n = 推倒重來。

這個過程是一個循環往復的過程，有的產品每一年都會推倒重來一次。

而這個過程是如何形成的呢?緣由之一是每次迭代過程當中都沒有用正確的架構方法來進行迭代形成的，就像在歪樓上繼續加蓋樓層同樣，最終仍是會倒塌(不過這個緣由並非惟一的緣由，其餘緣由留到後續文章中闡述)。

這真是一個悲傷的故事，可是又是一個時常發生的故事。或者說咱們大多數人都經歷過的場景。

要解決這個問題，那就須要在每次迭代中，都須要用正確的姿式對不對?要用對姿式其中有一個重要的緣由是架構。就像一幢大樓，架構設計得越有問題，這幢大樓被重造的可能性就越大。

這裏正確的姿式究竟是什麼姿式?接下來本文會闡述一整套架構方法論，該方法論中包含了詳細的架構推導邏輯，幫助咱們在工做中在各個粒度，各個層次作好架構工做。

咱們後續的文章中將會着重闡述如何經過自底向上以及自頂向下的兩種架構思考方式來解決這些問題，可是在那以前，咱們仍是先來聊聊什麼叫「架構」。

1.2 什麼是架構?

大概是在 11 年前左右，在土豆網作廣告平臺，同時也作視頻 CDN 的相關事情，當時作一個服務，基礎架構是 lighttpd + squid + tomcat，將靜態資源分離到 httpd，get 請求使用 squid 緩存，智能路由使用 HTTP post 請求，並讓 tomcat 提供服務，當時就以爲這就是架構。再後來，作了視頻 CDN 相關的基礎建設的工做，就以爲這就是作架構，關鍵那個時候也沒有人告訴咱們什麼架構，本身不知道本身不知道。

再後來慢慢成長，又去作了幾年中間件(包括高性能 RPC 和 JSR-170)，而後就以爲這也是作架構。當時也沒有前輩跟我講什麼是架構，那個時候的我對架構是沒有體系化認知的，都是憑着感受作的，是不知道本身不知道。

再後來，來到了阿里作應用研發和架構了，發現業務開發中也包含了各類方法論，而之前看過的建模相關的資料，在中間件等基礎設施上也沒有太大的感受，反而在業務技術領域發揮出了巨大的光芒。也發現越靠近用戶的架構，隨着企業的慢慢壯大會變得愈來愈重要。這個時候的我對架構認知是知道本身不知道了。

既然知道本身不知道了，那麼就是要追尋它，曾經我和很多業務的研發同窗討論過架構是什麼，撇去基礎設施架構和物理架構等視角不談(這些視角聊起來也是篇幅很長的)，我挑應用邏輯架構並從幾個角度來嘗試描述一下：

1)從架構的總原則的角度：儘量簡單(在當前場景下要儘量簡單便於擴展和維護)，可是不能太簡單(相對而言太過於簡單可能在場景上有所遺漏).

2)從架構的目的角度來考慮：既要解決過去的問題，也要解決如今的問題，還能適度解決將來的問題，這些問題既包含技術問題，更包含業務問題。

3)從形態之 2 維的角度來考慮：架構就是橫的問題，和豎的問題。橫就是分層，豎就是分區，橫豎都有抽象的事情要作。

4)從形態之 3 維的角度來考慮：架構是三維的，在 x 軸和 y 軸上有橫豎的問題，在z軸上還有粒度的問題。

5)從時間軸的角度來考慮：架構不是一層不變的，是隨着業務的發展在不斷變化的。

能夠看出，雖然我試圖從以上幾個視角對架構進行了描述，可是顯然這些描述都是見仁見智的觀點，是從某個角度來看架構。心裏裏我以爲本身提煉的高度是不夠的，實踐中的總結必須和業界的知識結合起來，我必須學習前人已經總結的體系。因而在不斷的蒐集資料的過程當中，我發如今 ISO/IEC 42010:20072 中對架構有以下定義：

The fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution.

這個最頂層抽象我我的以爲很是到位，根據這個定義，顯然，咱們在架構中須要：

• 職責明確的模塊或者組件
• 組件直接的關聯關係很是明確
• 須要有約束和指導原則

這個架構的定義很簡練，很實在。小到一個玩具，大到一個國家的運做均可以隱含着這樣的內容。

但這是一個廣義上定義的架構，通過一些總結思考，我以爲實際上具體到咱們平常的工做中，在不一樣的層次，會有更加精細化的架構分類。

1.3 架構有哪些分類

在工做中我遇到不一樣職位的人從不一樣的角度來描述架構，可是咱們鮮有能達成共識的，剛開始我也不知道爲啥討論不到一塊去，後來通過一段時間的糾結和深刻仔細的思考後，我發現不少時候你們描述的架構都不是同一個角度的東西，因而我嘗試從以下幾個角度劃分架構的類別，以幫助咱們在不一樣的場景和不一樣的人聊天時你們能夠聚焦，明確咱們究竟是在討論哪一種架構，以提高溝通效率，並儘快達成共識，目前這個劃分已經在咱們團隊基本達成共識。

值得注意的是，無論下面哪一種分類的架構，都符合上一節總的架構的定義：模塊(組件)+ 關係 + 約束 & 原則。

1. 產品功能架構

這個是產品經理最喜歡講的架構，通常來講，講咱們有什麼功能的時候，產品功能架構描述的是能作什麼，受衆羣體通常是使用產品的同窗。若是咱們作軟件設計時，不該該產出這玩意，而是應該產出應用邏輯架構和應用物理架 構。可是一旦咱們要對外宣講咱們的產品，好比咱們的接口有啥用，應該怎麼用，這個時候咱們講的應該是產品功能架構。

• 目的：指導用戶使用產品，因此模塊的聚合是從用戶視角出發的
• 受衆：使用產品的人
• 包含的內容：闡述產品功能模塊的能力：好比一輛汽車，方向盤有什麼功能，方向盤的按鈕上各區域的功能是什麼，儀表盤分紅哪些功能模塊，每一個功能模塊有什麼做用，油門踏板有什麼做用，剎車踏板有什麼做用。可是也不排除有些高階用戶須要明確知道變速箱的齒比等信息，因此在產品功能架構圖上也能夠描繪出來。
• 命名：這裏命名須要考慮如何取一個吸引人的名字(同時又能表達產品的能力)來吸引咱們的用戶前來使用，好比說之前常常有產品套用「納米」，又有產品套用「綠色」等等。

2. 業務能力架構

用來分析業務，業務概念架構是指擁有哪些業務模塊，且各自的能力是什麼，這張圖有助於咱們分析和理解業務需求，也有利於產品經理分析業務。因此業務概念架構和業務概念模型都是用在分析階段。

• 目的：研發人員和業務人員理解業務內在的概念和聯繫。
• 受衆：研發人員和業務人員，主要是給規劃業務的人使用。
• 包含的內容：業務能力，能力中的子能力。

3. 應用邏輯架構

軟件設計自己，模塊，粒度，職責，複用，等等，在講解軟件設計的時候，使用的是這個架構圖，這個架構圖是經過系統模型和業務概念架構推導而來。因此係統模型和應用邏輯架構都是用在軟件設計階段。

• 目的：指導軟件的研發。
• 受衆：研發人員，各層級架構師，各層級技術管理者。
• 包含的內容：闡述架構中各模塊的職責：如系統模型，技術模塊，技術模塊的關係，技術模塊的核心抽象，如何用設計模式來讓架構符合軟件設計原則，等等。若是拿汽車舉例，那就是發動機模塊中包含了哪些子模塊(活塞，曲軸，連桿，缸體，缸蓋，等等)發動機模塊和變速箱模塊之間的關聯關係是什麼，如何協同工做，和底盤的關聯關係是什麼，如何協同工做。發動機，底盤，變速箱，電子系統在整輛汽車中的職責，關係，約束是什麼。這些都是用來指導汽車研發的。而不是指導用戶如何使用這輛汽車的。
• 命名：這裏的命名須要樸實無華，精準的描述出職責，華而不實反而讓技術的同窗沒法理解這究竟是什麼玩意，致使實施的時候職責放錯地方，挖下大坑讓後人來填。

4. 應用物理(部署)架構

軟件部署時的架構，這張圖推導自應用邏輯架構，推導時重點邏輯架構如何落地，好比使用何種微服務容器，邏輯架構的模塊落地時應該是 package，仍是應用，也有多是一組應用，是否是要跨機房部署，甚至跨國部署等等。還須要考慮穩定性，性能，成本等話題。

5. 基礎設施架構

選擇什麼樣的中間件，存儲，監控，報警，等等。

6. 等等

1.4 能力和職責的區別

在平常的架構討論中，有的同窗常常談架構的能力，有的同窗常常談架構的職責，那麼能力和職責有什麼區別?跟產品的同窗打交道多了以後，發現產品同窗不少都是講能力，後來技術的同窗也開始講能力，而一般咱們架構的同窗原來說的都是職責，二者有什麼區別呢，我說說本身的理解：

1. 能力(產品功能模塊的能力)

是指一個產品能作什麼，好比中臺自己是一個產品，對使用中臺的同窗來講，咱們應該講中臺的能力(實際上是在講中臺這個產品的能力)。因此講能力是講給架構的使用者或者其餘想了解的人來聽的。

2. 職責(邏輯架構中各模塊的職責)

是指架構內模塊的職責，用來指導開發，好比中臺研發的同窗，應該講架構的職責，依賴，約束。因此講職責是講給研發的同窗，講給域內的架構師，講給域內的管理者來聽的，總的來講就是講給架構的實現者來講的。

簡單來講就是：能力是指產品的能力，職責是指架構內部的職責。若是架構自己也是一個產品需對外輸出(如中臺，或者其餘技術框架做爲產品輸出)，則對外輸出時，咱們應該講這個技術產品的能力(這個時候技術的同窗也就開始講能力了)。因此當咱們討論問題的時候，若是有的人在談產品能力，有人在談架構內部職責，那麼顯然已經不是在討論同一個話題了，請你們務必注意區分這種狀況，差之毫釐，謬以千里，雞同鴨講啊。

好比說兩個模塊 A 和 B，職責不同，可是依賴了相同的二方庫。那咱們不能說某個職責在這個二方庫裏。這個二方庫做爲某個獨立的技術小產品，提供了某些能力。可是履行職責的仍是 A 模塊或者 B 模塊。

1.5 應用邏輯架構的地位

正如前面咱們描述的架構分類所描述，有些架構和具體業務是無關的，有些架構是和具體業務息息相關的，好比說應用邏輯架構就是和業務息息相關，它來源於業務的抽象，甚至咱們能夠說：它是業務線技術架構設計中第一份產出。

既然他是首要的產出，咱們就必需要考慮應用邏輯架構中應該包含的三類主題：

• 模塊

• 依賴

• 約束

絕大部分的架構問題均可以概括成這三類主題，這些主題包含哪些內容呢?這就是本文接下來要介紹的內容，應用邏輯架構的設計不須要拍腦殼，是經過科學的方法體系推導出來的。

2、架構的兩種推導思路

架構的產出總的來講有兩種方式，一種是自頂向下的方式來推導架構，一種是自底向上的推導方式，並且兩種方式每每是相互結合來產出最合適的結果。而在業務線的同窗，可能接觸最多的是自底向上的推導的方式，自底向上的推導的方式也是本文中要重點講解的架構推導方式。

2.1 自頂向下的架構推導

自頂向下的推導的關鍵問題在問題定義，若是問題沒有被準確的定義，那麼自頂向下就沒法推導出正確的結果。假設問題被準確的定義了，如何自頂向下推導呢?

2.2 自底向上的架構推導

咱們在業務線作開發的同窗，天天確定跟不少需求打交道，這些需求哪裏來的?基本上有這三種產出：

1. 有些是來自產品方一拍腦殼產生的靈感
2. 有些是對數據進行了詳細的分析產出的產品策略
3. 有些是當前產品中暴露的一個個問題

產品方的這些詳細的需求來了以後，咱們是如何應對的呢?咱們首先和產品方一塊兒討論產品方案的合理性，在產品方案合理的基礎上，咱們來開始識別用例，開始了一系列軟件工程領域方面的措施。其總體過程以下圖所示：

自底向上推導邏輯架構就是最右邊表明的那條曲線。

這裏基本上就是本文接下來要重點闡述的：如何自底向上推導應用邏輯架構，這個過程就是一個抽象和架構的過程。

那麼咱們從總體方法論的介紹開始，採用總分總的結構，下面這張圖就是應用邏輯架構自底向上的推導路徑，這個推導路徑是有序的，每一個步驟都包含了大量的操做技巧，前一步作好，後一步纔有可能得出正確的結果。

這張圖中有幾個重點：

1)軟件研發分紅了兩個階段：

• 分析階段，也是咱們常說的問題空間領域建模，關鍵的一步是業務概念模型的輸出，而業務概念模型輸出的前置條件是從需求中分解出合理的用例集合。
• 設計階段，也是咱們常說的解決方案空間建模，以及應用邏輯架構。

2)圖中存在了箭頭這個東西，說明了咱們作架構推導的主要的思惟路徑，也說明作架構不須要拍腦殼，都是根據嚴密的邏輯推導出來的。

這個嚴密邏輯基本是一個自底向上的推導過程，底層的模型是經過建模方法演繹出來，邏輯架構中的各個模塊是經過概括的方法推導出來。那麼：

• 什麼地方應該用演繹，什麼地方應該用概括呢?
• 使用演繹的時候應該使用何種具體方法呢?
• 使用概括的時候應該使用何種具體方法呢?

咱們再留一個懸念，後面再講。

無論是演繹仍是概括，都是抽象工做的一部分，並且都須要素材，這裏的素材就是咱們對需求，對業務的理解，以及對技術的深度廣度的把握。沒有素材，方法論掌握再好也得不出結果。

素材哪裏來呢?

業務素材的來源大部分是你須要解決問題所在的領域，好比咱們在電商領域，那麼咱們就要多蒐集電商領域的業務知識。若是咱們在數據領域，天然要多蒐集數據業務的相關知識，以及咱們前文中講到的技術類的相關知識。

而技術素材是要求咱們在技術領域不斷的鑽研，不斷的擴展邊界，深度不斷增長，廣度也不斷增長。因此對於架構師來講計算機科學與技術是絕對要不斷精進的。

2.3 兩個方法的區別

自頂向下推導的一個前置條件就是你須要知道豬長什麼樣，在架構上就是你須要知道這個架構的原來是是什麼樣子的，解決什麼問題的。若是都不知道豬長什麼樣，那麼就無從判斷豬是否是適合當寵物了。此處須要有必定的業務領域理解力和領域經驗(包含：客戶的問題和痛點是什麼，怎麼分析出來的，當前的架構方案是什麼，當前的架構方案是如何解決這個問題的，將來的架構方案如何更好的解決這個問題)。

而自底向上推導則沒有這個問題，由於是看着豬來作推導的，知道豬的細節，這個細節的特色如何演繹，如何概括，最後得出結論。

因此當咱們不熟悉一個大的業務的時候，咱們自頂向下推導架構的難度是極大的，幾乎不能完成。不瞭解業務或技術狀況時定義出來的問題也未必是一個被正肯定義的問題，容易給人形成一個印象：瞎指揮。

這個時候如何在沒有知識背景的狀況下快速落地就得自底向上的來推導架構。在自底向上的過程當中慢慢熟悉業務。

可是若是工做中往往都是純粹的自底向上的推導架構，是沒法幫助咱們來作技術的前瞻性佈局的，此時架構師的成長就遇到的瓶頸，因此此時又要使用自頂向下的架構推導方式。

綜上所述，無論是自底向上，仍是自頂向下，都是架構師須要掌握的技能。

3、自底向上的架構方法：業務概念架構推導

這部份內容，我在 ICBU，村淘，一達通，菜鳥，AE 現場分享過。尤爲是在 AE，一達通和菜鳥，相關的同窗都拿出了當時的糾結你們好久的難題，咱們一塊兒使用了這樣的方法很快就分析出了業務概念模型，而且對模塊進行了簡要的劃分，造成概要的業務概念架構。通過大量的實戰，效果是很是明顯的。

3.1 模型的 3 個層次

在這裏，我把一些常見的概念集中起來，便於你們統一律念：

1. 業務概念模型，問題空間領域模型，信息模型是一樣的意思，這個層次上的實體咱們稱之爲概念實體，這部份內容是用在需求和業務分析上的，討論業務概念模型時徹底不須要考慮軟件的實現，這個過程是一個分析過程，即便不作軟件研發，作其餘的研發，相似的分析過程也應該是有的。

2. 系統模型，解決方案空間領域模型，邏輯模型是一樣的意思，這個層次上的實體，咱們稱之爲系統實體，或者邏輯實體，就是各類類，這個是用在軟件設計和軟件研發上的。

3. 存儲模型，數據模型，物理模型，在這裏也是一樣的意思，這個層次上的實體，咱們稱之爲數據實體，或者物理實體，也是用在軟件設計上。

這 3 個層次實際上是從 3 個角度在看待問題，他們之間是自上而下的轉換的關係，這裏尤爲要注意的兩個詞是：邏輯的，順序的推導。

這些不一樣層次的模型是應用邏輯架構的基礎!!!

3.2 模型的推導

3.2.1 用例集合推導概念模型

1. 根據用例集合推導業務概念模型
2. 根據用例中的動詞和量詞推導業務概念模型的關聯關係
3. 在特定的邊界內根據模型的職責概括子域

重要!重要!重要!這裏業務概念模型若是沒有分析正確，那麼下面要搞清楚是不容易的，這個分析部分是軟件邏輯架構設計的基礎。

這個環節須要咱們理解業務，更須要咱們掌握問題空間建模這一嚴謹的方法論，這樣咱們才能推導出合理的模型，整個過程是很是嚴謹的，很是符合邏輯的。

我在各 BU 分享現場作的屢次實戰演練之因此能成功的快速幫助同窗們梳理出前面花一兩個月都沒有理出的模型，徹底是由於於現場的同窗對業務的理解(由於討論以前我徹底沒有了解過對方的業務)和這套方法論(隱含在個人提問方式中)。因此說對業務的理解和方法論，二者缺一不可。

3.2.2 對業務概念模型進行概括

在模型產出以後，咱們要對模型進行概括。

什麼叫概括?

概括的意思是將全部的結果和想法合併，變成一種思惟概念。或者讓某個模型歸屬於某個已經存在的思惟概念。且這些模型或者模塊的職責不能超越這個高層次思惟概念的邊界。

爲何要概括?

實際上是爲了保證相近的職責模型聚攏在一塊兒從而保證職責的高內聚，同時明確出來的兩個子域的邊界，保證模塊和模塊之間的低耦合。

對業務概念模型的概括有助於作業務需求分析時判斷高內聚和低耦合，並且在系統模型上，對系統模型進行分類也有助於作應用邏輯架構中模塊的高內聚和低耦合，可是應用邏輯架構的不止高內聚和低耦合，還有其餘讓職責單一的方法，這些後面的章節會作介紹。

3.2.3 按職責來進行概括

接下來咱們來說講業務概念模型到業務概念架構判斷方法：

1)經過名詞定義來進行概括思惟概念

若是多個模型都在圍繞某個名詞，那麼咱們傾向將這個名詞提煉出來。產品在設計時，基本上咱們已經可以得一個粗略的業務模塊劃分，可是這個粗略的劃分是不必定是合理：

• 一是有可能咱們的理解是不到位的，致使用錯了名詞，這個咱們前面的文章中也提到過了。
• 二是這個結果也只是一個粗略的結果，須要進一步精化。

2)經過內聚的度量公式來進行概括

業務模型圖中，模型和模型連線(連線就是模型和模型鏈接線)數量除以模型的梳理獲得的值比較大的，那麼咱們能夠看作是內聚，這些連線比較緊密咱們趨向將其放到一個模塊中，連線不是那麼密切的，咱們趨向於將它們放置在不一樣的模塊中。而後咱們再觀察 連線數 / 模型數 觀察內聚度量是高了仍是低了，經過這樣的方式概括完成以後，咱們再來經過度量公式來度量各模塊的內聚和耦合程度。

3)其餘概括方式

若是咱們劃分出了基本模塊，發現還有一些模型不肯定應該放到哪些模塊中，咱們還可使用建立者原則和信息專家原則來判斷應該將該模型概括如哪一個模塊。

好比說，對存儲系統進行系統建模，表和字段的關係在業務概念模型中是1對n的關係(在系統模型中是組合關係，強生命週期依賴，可是這裏咱們尚未到討論應用邏輯架構的時候，只是在推導業務概念架構)，此時將字段放到另一個模塊顯然不合適，緣由是根據建立者原則。

當咱們不清楚把字段模型放到哪一個模塊的時候，咱們能夠看看字段這個模型是由誰建立的。

根據這條原則顯然這裏是表建立了字段，沒有表對象，就沒有字段對象，因此根據這條原則，咱們就傾向於把字段模型放到表所在的模塊中。

重點：失去了最底層合理且正確的演繹，上層的概括掌握的再好，也很可貴出合理的結果。

咱們來看看概括以後的效果示意圖：

圖中的 A1，A2，A3，A4 之類是示意圖，表示 A 模塊內部還存在子模塊，固然咱們實際上是先推導出子模塊，而後對子模塊再次進行高級別概括，造成父模塊。

父模塊層級再進行概括，就造成了祖父模塊，或者再向上造成曾祖父模塊等等。粒度越大的模塊，通常都對應更大的組織，越存在跨團隊溝通，因此劃清邊界的要求就越高。

3.3 業務流程

除了業務模型以外，業務流程也是咱們須要總結並明確的地方，這個地方主要明確的就是邊界和異常分支等等，尤爲是異常分支很是重要，不少業務方案的設計中對異常分支的考量是不重複的，這須要工程師對業務方案提出挑戰，以明確業務方案中的各類流程的異常分支。

3.4 業務概念架構總結

咱們工做中常見的推導有兩種方式，一種是自頂向下推導，一種是自底向上推導，顯然，兩種推導使用的方法是不同的。細心的讀者會發現，其實咱們剛剛說的問題空間領域模型和邊界分析這套方法就是自底向上的演繹和概括方法。

4、基礎邏輯架構推導(軟件設計階段)

前面咱們講到了業務分析階段，也是問題空間建模和問題空間業務概念架構梳理，業務分析階段和軟件沒有任何關係。但本文中它是軟件設計的前置條件，沒有 get 到點的同窗，請務必再把前一章仔細閱讀。

接下來咱們來說講軟件設計階段咱們須要產出的應用邏輯架構。

4.1 再談邏輯架構特性

文章開頭講到了邏輯架構的相關特色，咱們回顧一下：

• 應用邏輯架構的做用：咱們把前面那個例子再搬過來：若是拿汽車舉例，那就是發動機模塊中包含了哪些子模塊(活塞，曲軸，連桿，缸體，缸蓋，等等)發動機模塊和變速箱模塊之間的關聯關係是什麼，和底盤的關聯關係是什麼，發動機，底盤，變速箱，電子系統在整輛汽車中的職責，關係，約束是什麼。這些都是用來指導汽車研發的。而不是指導用戶如何使用這輛汽車的。
• 目的：因此係統模型和應用邏輯架構都是用在軟件設計階段，其目的是用來指導軟件的研發。
• 受衆：邏輯架構的受衆有哪些呢?通常是這些人：研發人員，各層級架構師，各層級技術管理者，總的來講他們都是架構的設計者和實現者。

這裏仍是請你們務必要跟產品功能架構區分開來，它們的受衆和目標是不同的。

4.2 基礎邏輯架構的推導概要

在文章開頭的圖中，咱們講到應用邏輯架構來源於系統模型，數據模型，業務概念架構，還有流程，以下圖所示。

接下來，咱們分別從三個角度來闡述邏輯架構的生成：

1. 業務概念架構
2. 模型(系統模型和數據模型)
3. 流程(系統調用流和數據流)

看到不少同窗畫的圖沒有區分出調用流和數據流，常常形成誤解，形成溝通效率降低，甚至不可以準確的說明問題。因此在畫圖的時候，必定要注意區分調用流和數據流。

接下來就根據業務概念架構和系統模型及流程來推導一下應用架構(邏輯架構)。咱們來看一下一個簡單的邏輯架構構成的 gif 示意圖：

從這張圖中，咱們能夠看出應用邏輯架構是如何一步步被構成的，整個過程存在如下關鍵點：

1)在業務概念架構的基礎上推演應用邏輯架構。

2)根據流程和系統模型來完善應用邏輯架構。

3)橫向提煉模塊的問題：要實現業務模塊，須要什麼非業務模塊的支撐，好比監控，報警，配置等等，而這部份內容每每仍是可複用的。在上述動畫中，能夠理解成移動到最右側的部分，固然能夠移動到左側，只是動畫中沒有體現出來。

4)縱向提煉模塊問題：有相似職責的模塊在技術實現上是否能夠提煉成可複用內容，提煉的結果多是：

• 獨立的服務複用，在上述動畫中，能夠理解成最下方。
• 或者二方庫複用，在上述動畫中，能夠理解成最左或者最右側。
• 等

5)還有一些模塊是爲了支撐性能或者穩定性的，並不是是從業務概念模型提煉而來，如圖中深藍色的模塊。

最終，出現的邏輯架構是分層的和分片的邏輯架構，下面咱們來一步步闡述這個過程。

4.3 根據業務概念架構推演

業務概念架構圖產出以後，基本上，咱們邏輯架構的初步模型就具有了。因此咱們能夠理解成，第一步就是把業務概念架構直接先搬到應用邏輯架構中來，此處就不用多闡述了。

囉嗦兩句：尤爲是較爲頂層的粗粒度業務架構，一個是自頂向下分解得來，一個是自底向上演繹和概括得來。而自頂向下分解尤爲考驗人對業務的理解能力，若是對業務理解不透徹，那很難產出合理的粗粒度業務概念架構。

4.4 根據系統流程進行推演模塊

當業務概念架構產出以後，邏輯架構的骨架初成，接下來就是在這個框架上去填充內容。第一步就是根據流程來進行模塊劃分。

總結一下，這裏的方法就是，先根據業務流程，分解出系統時序圖，根據時序圖開始對模塊進行概括，從而獲得粒度更大的模塊。

這是粒度比較細的根據流程劃分模塊的案例，在粒度更大的流程，此方法一樣適用，看你們是工做在何種粒度上。

經過流程來進行推導是咱們平常工做必不可少的一部分，尤爲當不少場景的流程具備業務共同點時，那麼能夠考慮提煉出這些業務共同點，以提高研發的效率。

4.5 非業務線系統根據流程推導模塊案例

除了對流程進行概括以外，咱們還能夠對系統模型進行概括。咱們知道，業務概念模型通常能夠直接轉換爲系統模型，可是系統模型並不僅是業務領域相關的模型，好比查詢模型是一個常常出現的，這在 OLTP 的場景十分常見，而在 OLAP 的場景簡直就是頂樑柱。很是常見的就是 SQL parser 模塊，下圖是 spark 體系中 SQL SQL 的主要流程和對應的模型，根據這個模型咱們基本上也能夠梳理出模塊：

根據這個流程，咱們發現了什麼?咱們發現了 spark 中是這樣分模塊的(這裏面的模塊已經落地成 package 了)：

因此說按照業務流程轉換成的系統流程來推導模塊是很是重要的手段。

除此以外須要還須要強調的是，流程和模塊同樣，也是有粒度的，相同粒度的流程節點放在一塊兒才更加容易推導出合理的架構模塊。至於什麼叫相同粒度，請參考一下《金字塔原理》。

流程的粒度很重要，粒度粒度粒度，請重視流程的粒度。

4.6 根據性能 & 穩定性 & 成本等進行提煉模塊

前面講的都是從業務的角度來闡述架構的推導，接下來咱們從計算機科學與技術的角度來闡述一下這些非功能性模塊的推導，這裏拿性能來舉個例子吧。

數據分析的報表場景下降 RT 的方案

在一些數據分析產品中，績效監控及報表展現是一個很是重要的場景，這個場景下的數據量是比較大的，爲了下降 RT，咱們不得不經過 ETL 對數據進行預計算，將原有的大表清洗成聚合以後的小表，以加快查詢的速度。這樣作的缺點是每次進行報表的修改，就要進行相關的ETL邏輯，高時間和人力成本，高性能。

爲了把高時間和人力成本 & 高性能轉換成低成本&高性能，咱們須要把人工操做轉換成自動操做，把 ETL 的過程去除。

第一個選擇是將一個大表的數據存儲到另一個支持大數據下高性能的查詢引擎，這樣就極大的減小了 ETL 的操做，可是這樣就帶來一個問題，就是大數據量下把數據從 ODPS 導入到某個 ROLAP 的查詢引擎中是比較耗時的，並且每次查詢須要進行在海量數據中進行大量的 scan，但實際上獲取的數據量並不大。這樣的查詢的 RT 依然須要亞秒級。

第二個選擇是根據報表的定義，自動的將判斷出用戶須要查詢什麼結果，將查詢結果提早計算出來，而後只把這些少許的預計算後的結果導入到 ROLAP 引擎中(具體請參考 apache 開源項目 Kylin)。而後在報表的場景下，查詢的 RT 降低到了百毫秒級。

顯然咱們要實現第二種方式，這個時候在業務功能沒有增長的狀況下，咱們必需要增長一個模塊，在咱們的產品中，咱們稱之爲 intelligent cube，由於咱們這裏引入了機器學習算法對 cube 的構建進行了預測，無需或者只需很是少許的人爲參與。

最後致使邏輯架構中有部分是來自業務概念架構推導而來，有部分是系統流程推導而來，有部分是由於性能 & 成本的須要產生的設計。

注意：理論上來說，邏輯架構上須要指出模塊之間的依賴關係，只是若是這樣，不是特別美觀，因此就根據上下和左右的位置來大概描述模塊之間的關係了。

這兩個案例基本能夠說明，根據性能 & 成本 & 穩定性推導出來的模塊也是邏輯架構組成的重要部分。

可是這個還只是一個場景一個場景來解決 RT 問題，雖然 icube 本身內部是有個體系的，可是經過這樣的方式來解決 RT 問題對於整個架構來講也是自底向上構建的一個環節。在下一篇文章中，咱們將會闡述相同的案例，可是思路是自頂向下來構建性能領域的體系化架構。一樣一個事情，用不一樣的思路來作，對總目標的幫助是不同的，並且兩個方法是互補的，誰都少不了。

這樣的模塊是如何得來的呢?

看上去咱們都已經知道了系統中有很多相似的純技術相關的模塊，可是這些模塊內部是如何設計出來的呢?

通常來講有以下方法幫助咱們作這些模塊的內部設計：

1)調查業界的開源技術類產品中是否有相似功能的，好比預計算在業界有 kylin，而星環等專業大數據公司也都有本身的 cube 預計算產品。

2)查閱業界相關的論文，好比說在預計算領域就已經研究了幾十年，計算機發展的不一樣階段有不一樣的論文，網上一搜一大堆，不斷研究，必對工做有幫助。

3)多關注業界的牛人，看看他們在想什麼，說什麼，參加參加相關的會議。

4)本身經過邏輯和數據結構 & 算法推導出來。

若是每次都只經過本身的邏輯和本身已經掌握的知識來進行方案的推導是不夠的，一個是咱們的技能有時候和事情是不匹配的，可是咱們每每不知道這樣的事實的存在，因此此時必定要虛心學習，請教他人，擴展本身的知識邊界，才能作出更好的方案和技術決策。

4.7 應用邏輯架構推導小結

根據上文所述，基本上應用邏輯架構的推導有 4 個子路徑，他們分別是：

1. 業務概念架構：業務概念架構來自於業務概念模型和業務流程
2. 系統模型：來自於業務概念模型
3. 系統流程：來自業務流程
4. 非功能性的系統支撐：來自對性能，穩定性，成本的須要

每一個子路徑中都存在相關的具體方法。

若是真的要想學習東西，並且想學的更快更深刻，就要關注本身如何集中注意力，要思考本身的思考方式，研究本身的研究方式。

Blog: https://blog.yilon.top