一、背景
1.1 架構中的問題識別
需求分析，架構實現，(新需求，架構改動)* n = 推倒重來。
這個過程是一個循環往復的過程，有的產品每年都會推倒重來一次。
而這個過程是如何造成的呢?原因之一是每次迭代過程中都沒有用正確的架構方法來進行迭代造成的，就像在歪樓上繼續加蓋樓層一樣，最終還是會倒塌(不過這個原因并不是唯一的原因，其他原因留到后續文章中闡述)。
這真是一個悲傷的故事，但是又是一個時常發生的故事?；蛘哒f我們大多數人都經歷過的場景。
要解決這個問題，那就需要在每次迭代中，都需要用正確的姿勢對不對?要用對姿勢其中有一個重要的原因是架構。就像一幢大樓，架構設計得越有問題，這幢大樓被重造的可能性就越大。
這里正確的姿勢到底是什么姿勢?接下來本文會闡述一整套架構方法論，該方法論中包含了詳細的架構推導邏輯，幫助我們在工作中在各個粒度，各個層次做好架構工作。
我們后續的文章中將會著重闡述如何通過自底向上以及自頂向下的兩種架構思考方式來解決這些問題，但是在那之前，我們還是先來聊聊什么叫“架構”。
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.1 自頂向下的架構推導
自頂向下的推導的關鍵問題在問題定義，如果問題沒有被準確的定義，那么自頂向下就無法推導出正確的結果。假設問題被準確的定義了，如何自頂向下推導呢?
2.2 自底向上的架構推導
我們在業務線做開發的同學，每天肯定跟很多需求打交道，這些需求哪里來的?基本上有這三種產出：
- 有些是來自產品方一拍腦袋產生的靈感
- 有些是對數據進行了詳細的分析產出的產品策略
- 有些是當前產品中暴露的一個個問題
產品方的這些詳細的需求來了之后，我們是如何應對的呢?我們首先和產品方一起討論產品方案的合理性，在產品方案合理的基礎上，我們來開始識別用例，開始了一系列軟件工程領域方面的措施。其整體過程如下圖所示：
自底向上推導邏輯架構就是最右邊代表的那條曲線。
這里基本上就是本文接下來要重點闡述的：如何自底向上推導應用邏輯架構，這個過程就是一個抽象和架構的過程。
那么我們從整體方法論的介紹開始，采用總分總的結構，下面這張圖就是應用邏輯架構自底向上的推導路徑，這個推導路徑是有序的，每個步驟都包含了大量的操作技巧，前一步做好，后一步才有可能得出正確的結果。
這張圖中有幾個重點：
1)軟件研發分成了兩個階段：
- 分析階段，也是我們常說的問題空間領域建模，關鍵的一步是業務概念模型的輸出，而業務概念模型輸出的前置條件是從需求中分解出合理的用例集合。
- 設計階段，也是我們常說的解決方案空間建模，以及應用邏輯架構。
2)圖中存在了箭頭這個東西，說明了我們做架構推導的主要的思維路徑，也說明做架構不需要拍腦袋，都是根據嚴密的邏輯推導出來的。
這個嚴密邏輯基本是一個自底向上的推導過程，底層的模型是通過建模方法演繹出來，邏輯架構中的各個模塊是通過歸納的方法推導出來。那么：
- 什么地方應該用演繹，什么地方應該用歸納呢?
- 使用演繹的時候應該使用何種具體方法呢?
- 使用歸納的時候應該使用何種具體方法呢?
我們再留一個懸念，后面再講。
不管是演繹還是歸納，都是抽象工作的一部分，而且都需要素材，這里的素材就是我們對需求，對業務的理解，以及對技術的深度廣度的把握。沒有素材，方法論掌握再好也得不出結果。
素材哪里來呢?
業務素材的來源大部分是你需要解決問題所在的領域，比如我們在電商領域，那么我們就要多搜集電商領域的業務知識。如果我們在數據領域，自然要多搜集數據業務的相關知識，以及我們前文中講到的技術類的相關知識。
而技術素材是要求我們在技術領域不斷的鉆研，不斷的擴展邊界，深度不斷增加，廣度也不斷增加。所以對于架構師來說計算機科學與技術是絕對要不斷精進的。
2.3 兩個方法的區別
自頂向下推導的一個前置條件就是你需要知道豬長什么樣，在架構上就是你需要知道這個架構的原來是是什么樣子的，解決什么問題的。如果都不知道豬長什么樣，那么就無從判斷豬是不是適合當寵物了。此處需要有一定的業務領域理解力和領域經驗(包含：客戶的問題和痛點是什么，怎么分析出來的，當前的架構方案是什么，當前的架構方案是如何解決這個問題的，未來的架構方案如何更好的解決這個問題)。
而自底向上推導則沒有這個問題，因為是看著豬來做推導的，知道豬的細節，這個細節的特點如何演繹，如何歸納，最后得出結論。
所以當我們不熟悉一個大的業務的時候，我們自頂向下推導架構的難度是極大的，幾乎不能完成。不了解業務或技術情況時定義出來的問題也未必是一個被正確定義的問題，容易給人造成一個印象：瞎指揮。
這個時候如何在沒有知識背景的情況下快速落地就得自底向上的來推導架構。在自底向上的過程中慢慢熟悉業務。
但是如果工作中每每都是純粹的自底向上的推導架構，是無法幫助我們來做技術的前瞻性布局的，此時架構師的成長就遇到的瓶頸，所以此時又要使用自頂向下的架構推導方式。
綜上所述，不管是自底向上，還是自頂向下，都是架構師需要掌握的技能。
三、自底向上的架構方法：業務概念架構推導
這部分內容，我在 ICBU，村淘，一達通，菜鳥，AE 現場分享過。尤其是在 AE，一達通和菜鳥，相關的同學都拿出了當時的糾結大家很久的難題，我們一起使用了這樣的方法很快就分析出了業務概念模型，并且對模塊進行了簡要的劃分，形成概要的業務概念架構。經過大量的實戰，效果是非常明顯的。
3.1 模型的 3 個層次
在這里，我把一些常見的概念集中起來，便于大家統一概念：
1)業務概念模型，問題空間領域模型，信息模型是同樣的意思，這個層次上的實體我們稱之為概念實體，這部分內容是用在需求和業務分析上的，討論業務概念模型時完全不需要考慮軟件的實現，這個過程是一個分析過程，即使不做軟件研發，做其他的研發，類似的分析過程也應該是有的。
2)系統模型，解決方案空間領域模型，邏輯模型是同樣的意思，這個層次上的實體，我們稱之為系統實體，或者邏輯實體，就是各種類，這個是用在軟件設計和軟件研發上的。
3)存儲模型，數據模型，物理模型，在這里也是同樣的意思，這個層次上的實體，我們稱之為數據實體，或者物理實體，也是用在軟件設計上。
這 3 個層次其實是從 3 個角度在看待問題，他們之間是自上而下的轉換的關系，這里尤其要注意的兩個詞是：邏輯的，順序的推導。
這些不同層次的模型是應用邏輯架構的基礎!!!
3.2 模型的推導
3.2.1 用例集合推導概念模型
- 根據用例集合推導業務概念模型
- 根據用例中的動詞和量詞推導業務概念模型的關聯關系
- 在特定的邊界內根據模型的職責歸納子域
重要!重要!重要!這里業務概念模型如果沒有分析正確，那么下面要搞清楚是不容易的，這個分析部分是軟件邏輯架構設計的基礎。
這個環節需要我們理解業務，更需要我們掌握問題空間建模這一嚴謹的方法論，這樣我們才能推導出合理的模型，整個過程是非常嚴謹的，非常符合邏輯的。
我在各 BU 分享現場做的多次實戰演練之所以能成功的快速幫助同學們梳理出前面花一兩個月都沒有理出的模型，完全是因為于現場的同學對業務的理解(因為討論之前我完全沒有了解過對方的業務)和這套方法論(隱含在我的提問方式中)。所以說對業務的理解和方法論，兩者缺一不可。
3.2.2 對業務概念模型進行歸納
在模型產出之后，我們要對模型進行歸納。
什么叫歸納?
歸納的意思是將所有的結果和想法合并，變成一種思維概念?；蛘咦屇硞€模型歸屬于某個已經存在的思維概念。且這些模型或者模塊的職責不能超越這個高層次思維概念的邊界。
為什么要歸納?
其實是為了保證相近的職責模型聚攏在一起從而保證職責的高內聚，同時明確出來的兩個子域的邊界，保證模塊和模塊之間的低耦合。
對業務概念模型的歸納有助于做業務需求分析時判斷高內聚和低耦合，而且在系統模型上，對系統模型進行分類也有助于做應用邏輯架構中模塊的高內聚和低耦合，但是應用邏輯架構的不止高內聚和低耦合，還有其他讓職責單一的方法，這些后面的章節會做介紹。
3.2.3 按職責來進行歸納
接下來我們來講講業務概念模型到業務概念架構判斷方法：
1)通過名詞定義來進行歸納思維概念
如果多個模型都在圍繞某個名詞，那么我們傾向將這個名詞提煉出來。產品在設計時，基本上我們已經能夠得一個粗略的業務模塊劃分，但是這個粗略的劃分是不一定是合理：
- 一是有可能我們的理解是不到位的，導致用錯了名詞，這個我們前面的文章中也提到過了。
- 二是這個結果也只是一個粗略的結果，需要進一步精化。
2)通過內聚的度量公式來進行歸納
業務模型圖中，模型和模型連線(連線就是模型和模型連接線)數量除以模型的梳理得到的值比較大的，那么我們可以看做是內聚，這些連線比較緊密我們趨向將其放到一個模塊中，連線不是那么密切的，我們趨向于將它們放置在不同的模塊中。然后我們再觀察 連線數 / 模型數 觀察內聚度量是高了還是低了，通過這樣的方式歸納完成之后，我們再來通過度量公式來度量各模塊的內聚和耦合程度。
3)其他歸納方式
如果我們劃分出了基本模塊，發現還有一些模型不確定應該放到哪些模塊中，我們還可以使用創建者原則和信息專家原則來判斷應該將該模型歸納如哪個模塊。
比如說，對存儲系統進行系統建模，表和字段的關系在業務概念模型中是1對n的關系(在系統模型中是組合關系，強生命周期依賴，但是這里我們還沒有到討論應用邏輯架構的時候，只是在推導業務概念架構)，此時將字段放到另外一個模塊顯然不合適，原因是根據創建者原則。
當我們不清楚把字段模型放到哪個模塊的時候，我們可以看看字段這個模型是由誰創建的。
根據這條原則顯然這里是表創建了字段，沒有表對象，就沒有字段對象，所以根據這條原則，我們就傾向于把字段模型放到表所在的模塊中。
重點：失去了最底層合理且正確的演繹，上層的歸納掌握的再好，也很難得出合理的結果。
我們來看看歸納之后的效果示意圖：
圖中的 A1，A2，A3，A4 之類是示意圖，表示 A 模塊內部還存在子模塊，當然我們其實是先推導出子模塊，然后對子模塊再次進行高級別歸納，形成父模塊。
父模塊層級再進行歸納，就形成了祖父模塊，或者再向上形成曾祖父模塊等等。粒度越大的模塊，一般都對應更大的組織，越存在跨團隊溝通，所以劃清邊界的要求就越高。
3.3 業務流程
除了業務模型之外，業務流程也是我們需要總結并明確的地方，這個地方主要明確的就是邊界和異常分支等等，尤其是異常分支非常重要，很多業務方案的設計中對異常分支的考量是不重復的，這需要工程師對業務方案提出挑戰，以明確業務方案中的各種流程的異常分支。
3.4 業務概念架構總結
我們工作中常見的推導有兩種方式，一種是自頂向下推導，一種是自底向上推導，顯然，兩種推導使用的方法是不一樣的。細心的讀者會發現，其實我們剛剛說的問題空間領域模型和邊界分析這套方法就是自底向上的演繹和歸納方法。
四、基礎邏輯架構推導(軟件設計階段)
前面我們講到了業務分析階段，也是問題空間建模和問題空間業務概念架構梳理，業務分析階段和軟件沒有任何關系。但本文中它是軟件設計的前置條件，沒有 get 到點的同學，請務必再把前一章仔細閱讀。
接下來我們來講講軟件設計階段我們需要產出的應用邏輯架構。
4.1 再談邏輯架構特性
文章開頭講到了邏輯架構的相關特點，我們回顧一下：
- 應用邏輯架構的作用：我們把前面那個例子再搬過來：如果拿汽車舉例，那就是發動機模塊中包含了哪些子模塊(活塞，曲軸，連桿，缸體，缸蓋，等等)發動機模塊和變速箱模塊之間的關聯關系是什么，和底盤的關聯關系是什么，發動機，底盤，變速箱，電子系統在整輛汽車中的職責，關系，約束是什么。這些都是用來指導汽車研發的。而不是指導用戶如何使用這輛汽車的。
- 目的：所以系統模型和應用邏輯架構都是用在軟件設計階段，其目的是用來指導軟件的研發。
- 受眾：邏輯架構的受眾有哪些呢?一般是這些人：研發人員，各層級架構師，各層級技術管理者，總的來說他們都是架構的設計者和實現者。
這里還是請大家務必要跟產品功能架構區分開來，它們的受眾和目標是不一樣的。
4.2 基礎邏輯架構的推導概要
在文章開頭的圖中，我們講到應用邏輯架構來源于系統模型，數據模型，業務概念架構，還有流程，如下圖所示。
接下來，我們分別從三個角度來闡述邏輯架構的生成：
- 業務概念架構
- 模型(系統模型和數據模型)
- 流程(系統調用流和數據流)
看到很多同學畫的圖沒有區分出調用流和數據流，經常造成誤解，造成溝通效率下降，甚至不能夠準確的說明問題。所以在畫圖的時候，一定要注意區分調用流和數據流。
接下來就根據業務概念架構和系統模型及流程來推導一下應用架構(邏輯架構)。我們來看一下一個簡單的邏輯架構構成的 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 個子路徑，他們分別是：
- 業務概念架構：業務概念架構來自于業務概念模型和業務流程
- 系統模型：來自于業務概念模型
- 系統流程：來自業務流程
- 非功能性的系統支撐：來自對性能，穩定性，成本的需要
每個子路徑中都存在相關的具體方法。
如果真的要想學習東西，而且想學的更快更深入，就要關注自己如何集中注意力，要思考自己的思考方式，研究自己的研究方式。
