從方法到思維：什么是應(yīng)用邏輯架構(gòu)的正確姿勢？-魔扣目錄

一、背景

1.1 架構(gòu)中的問題識別

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

這個過程是一個循環(huán)往復(fù)的過程，有的產(chǎn)品每年都會推倒重來一次。

而這個過程是如何造成的呢?原因之一是每次迭代過程中都沒有用正確的架構(gòu)方法來進行迭代造成的，就像在歪樓上繼續(xù)加蓋樓層一樣，最終還是會倒塌(不過這個原因并不是唯一的原因，其他原因留到后續(xù)文章中闡述)。

這真是一個悲傷的故事，但是又是一個時常發(fā)生的故事。或者說我們大多數(shù)人都經(jīng)歷過的場景。

要解決這個問題，那就需要在每次迭代中，都需要用正確的姿勢對不對?要用對姿勢其中有一個重要的原因是架構(gòu)。就像一幢大樓，架構(gòu)設(shè)計得越有問題，這幢大樓被重造的可能性就越大。

這里正確的姿勢到底是什么姿勢?接下來本文會闡述一整套架構(gòu)方法論，該方法論中包含了詳細的架構(gòu)推導邏輯，幫助我們在工作中在各個粒度，各個層次做好架構(gòu)工作。

我們后續(xù)的文章中將會著重闡述如何通過自底向上以及自頂向下的兩種架構(gòu)思考方式來解決這些問題，但是在那之前，我們還是先來聊聊什么叫“架構(gòu)”。

1.2 什么是架構(gòu)?

大概是在 11 年前左右，在土豆網(wǎng)做廣告平臺，同時也做視頻 CDN 的相關(guān)事情，當時做一個服務(wù)，基礎(chǔ)架構(gòu)是 lighttpd + squid + Tomcat，將靜態(tài)資源分離到 httpd，get 請求使用 squid 緩存，智能路由使用 HTTP post 請求，并讓 tomcat 提供服務(wù)，當時就覺得這就是架構(gòu)。再后來，做了視頻 CDN 相關(guān)的基礎(chǔ)建設(shè)的工作，就覺得這就是做架構(gòu)，關(guān)鍵那個時候也沒有人告訴我們什么架構(gòu)，自己不知道自己不知道。

再后來慢慢成長，又去做了幾年中間件(包括高性能 RPC 和 JSR-170)，然后就覺得這也是做架構(gòu)。當時也沒有前輩跟我講什么是架構(gòu)，那個時候的我對架構(gòu)是沒有體系化認知的，都是憑著感覺做的，是不知道自己不知道。

再后來，來到了阿里做應(yīng)用研發(fā)和架構(gòu)了，發(fā)現(xiàn)業(yè)務(wù)開發(fā)中也包含了各種方法論，而以前看過的建模相關(guān)的資料，在中間件等基礎(chǔ)設(shè)施上也沒有太大的感覺，反而在業(yè)務(wù)技術(shù)領(lǐng)域發(fā)揮出了巨大的光芒。也發(fā)現(xiàn)越靠近用戶的架構(gòu)，隨著企業(yè)的慢慢壯大會變得越來越重要。這個時候的我對架構(gòu)認知是知道自己不知道了。

既然知道自己不知道了，那么就是要追尋它，曾經(jīng)我和不少業(yè)務(wù)的研發(fā)同學討論過架構(gòu)是什么，撇去基礎(chǔ)設(shè)施架構(gòu)和物理架構(gòu)等視角不談(這些視角聊起來也是篇幅很長的)，我挑應(yīng)用邏輯架構(gòu)并從幾個角度來嘗試描述一下：

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

2)從架構(gòu)的目的角度來考慮：既要解決過去的問題，也要解決現(xiàn)在的問題，還能適度解決未來的問題，這些問題既包含技術(shù)問題，更包含業(yè)務(wù)問題。

3)從形態(tài)之 2 維的角度來考慮：架構(gòu)就是橫的問題，和豎的問題。橫就是分層，豎就是分區(qū)，橫豎都有抽象的事情要做。

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

5)從時間軸的角度來考慮：架構(gòu)不是一層不變的，是隨著業(yè)務(wù)的發(fā)展在不斷變化的。

可以看出，雖然我試圖從以上幾個視角對架構(gòu)進行了描述，但是顯然這些描述都是見仁見智的觀點，是從某個角度來看架構(gòu)。內(nèi)心里我覺得自己提煉的高度是不夠的，實踐中的總結(jié)必須和業(yè)界的知識結(jié)合起來，我必須學習前人已經(jīng)總結(jié)的體系。于是在不斷的搜集資料的過程中，我發(fā)現(xiàn)在 ISO/IEC 42010:20072 中對架構(gòu)有如下定義：

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.

這個最頂層抽象我個人覺得非常到位，根據(jù)這個定義，顯然，我們在架構(gòu)中需要：

職責明確的模塊或者組件
組件直接的關(guān)聯(lián)關(guān)系非常明確
需要有約束和指導原則

這個架構(gòu)的定義很簡練，很實在。小到一個玩具，大到一個國家的運作都可以隱含著這樣的內(nèi)容。

但這是一個廣義上定義的架構(gòu)，經(jīng)過一些總結(jié)思考，我覺得實際上具體到我們?nèi)粘５墓ぷ髦校诓煌膶哟危瑫懈泳毣募軜?gòu)分類。

1.3 架構(gòu)有哪些分類

在工作中我遇到不同職位的人從不同的角度來描述架構(gòu)，但是我們鮮有能達成共識的，剛開始我也不知道為啥討論不到一塊去，后來經(jīng)過一段時間的糾結(jié)和深入仔細的思考后，我發(fā)現(xiàn)很多時候大家描述的架構(gòu)都不是同一個角度的東西，于是我嘗試從如下幾個角度劃分架構(gòu)的類別，以幫助我們在不同的場景和不同的人聊天時大家可以聚焦，明確我們到底是在討論哪種架構(gòu)，以提升溝通效率，并盡快達成共識，目前這個劃分已經(jīng)在我們團隊基本達成共識。

值得注意的是，不管下面哪種分類的架構(gòu)，都符合上一節(jié)總的架構(gòu)的定義：模塊(組件)+ 關(guān)系 + 約束 & 原則。

1. 產(chǎn)品功能架構(gòu)

這個是產(chǎn)品經(jīng)理最喜歡講的架構(gòu)，一般來說，講我們有什么功能的時候，產(chǎn)品功能架構(gòu)描述的是能做什么，受眾群體一般是使用產(chǎn)品的同學。如果我們做軟件設(shè)計時，不應(yīng)該產(chǎn)出這玩意，而是應(yīng)該產(chǎn)出應(yīng)用邏輯架構(gòu)和應(yīng)用物理架構(gòu)。但是一旦我們要對外宣講我們的產(chǎn)品，比如我們的接口有啥用，應(yīng)該怎么用，這個時候我們講的應(yīng)該是產(chǎn)品功能架構(gòu)。

目的：指導用戶使用產(chǎn)品，所以模塊的聚合是從用戶視角出發(fā)的
受眾：使用產(chǎn)品的人
包含的內(nèi)容：闡述產(chǎn)品功能模塊的能力：比如一輛汽車，方向盤有什么功能，方向盤的按鈕上各區(qū)域的功能是什么，儀表盤分成哪些功能模塊，每個功能模塊有什么作用，油門踏板有什么作用，剎車踏板有什么作用。但是也不排除有些高階用戶需要明確知道變速箱的齒比等信息，所以在產(chǎn)品功能架構(gòu)圖上也可以描繪出來。
命名：這里命名需要考慮如何取一個吸引人的名字(同時又能表達產(chǎn)品的能力)來吸引我們的用戶前來使用，比如說以前經(jīng)常有產(chǎn)品套用“納米”，又有產(chǎn)品套用“綠色”等等。

2. 業(yè)務(wù)能力架構(gòu)

用來分析業(yè)務(wù)，業(yè)務(wù)概念架構(gòu)是指擁有哪些業(yè)務(wù)模塊，且各自的能力是什么，這張圖有助于我們分析和理解業(yè)務(wù)需求，也有利于產(chǎn)品經(jīng)理分析業(yè)務(wù)。所以業(yè)務(wù)概念架構(gòu)和業(yè)務(wù)概念模型都是用在分析階段。

目的：研發(fā)人員和業(yè)務(wù)人員理解業(yè)務(wù)內(nèi)在的概念和聯(lián)系。
受眾：研發(fā)人員和業(yè)務(wù)人員，主要是給規(guī)劃業(yè)務(wù)的人使用。
包含的內(nèi)容：業(yè)務(wù)能力，能力中的子能力。

3. 應(yīng)用邏輯架構(gòu)

軟件設(shè)計本身，模塊，粒度，職責，復(fù)用，等等，在講解軟件設(shè)計的時候，使用的是這個架構(gòu)圖，這個架構(gòu)圖是通過系統(tǒng)模型和業(yè)務(wù)概念架構(gòu)推導而來。所以系統(tǒng)模型和應(yīng)用邏輯架構(gòu)都是用在軟件設(shè)計階段。

目的：指導軟件的研發(fā)。
受眾：研發(fā)人員，各層級架構(gòu)師，各層級技術(shù)管理者。
包含的內(nèi)容：闡述架構(gòu)中各模塊的職責：如系統(tǒng)模型，技術(shù)模塊，技術(shù)模塊的關(guān)系，技術(shù)模塊的核心抽象，如何用設(shè)計模式來讓架構(gòu)符合軟件設(shè)計原則，等等。如果拿汽車舉例，那就是發(fā)動機模塊中包含了哪些子模塊(活塞，曲軸，連桿，缸體，缸蓋，等等)發(fā)動機模塊和變速箱模塊之間的關(guān)聯(lián)關(guān)系是什么，如何協(xié)同工作，和底盤的關(guān)聯(lián)關(guān)系是什么，如何協(xié)同工作。發(fā)動機，底盤，變速箱，電子系統(tǒng)在整輛汽車中的職責，關(guān)系，約束是什么。這些都是用來指導汽車研發(fā)的。而不是指導用戶如何使用這輛汽車的。
命名：這里的命名需要樸實無華，精準的描述出職責，華而不實反而讓技術(shù)的同學無法理解這到底是什么玩意，導致實施的時候職責放錯地方，挖下大坑讓后人來填。

4. 應(yīng)用物理(部署)架構(gòu)

軟件部署時的架構(gòu)，這張圖推導自應(yīng)用邏輯架構(gòu)，推導時重點邏輯架構(gòu)如何落地，比如使用何種微服務(wù)容器，邏輯架構(gòu)的模塊落地時應(yīng)該是 package，還是應(yīng)用，也有可能是一組應(yīng)用，是不是要跨機房部署，甚至跨國部署等等。還需要考慮穩(wěn)定性，性能，成本等話題。

5. 基礎(chǔ)設(shè)施架構(gòu)

選擇什么樣的中間件，存儲，監(jiān)控，報警，等等。

6. 等等

1.4 能力和職責的區(qū)別

在日常的架構(gòu)討論中，有的同學經(jīng)常談架構(gòu)的能力，有的同學經(jīng)常談架構(gòu)的職責，那么能力和職責有什么區(qū)別?跟產(chǎn)品的同學打交道多了之后，發(fā)現(xiàn)產(chǎn)品同學很多都是講能力，后來技術(shù)的同學也開始講能力，而通常我們架構(gòu)的同學原來講的都是職責，兩者有什么區(qū)別呢，我說說自己的理解：

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

是指一個產(chǎn)品能做什么，比如中臺本身是一個產(chǎn)品，對使用中臺的同學來說，我們應(yīng)該講中臺的能力(其實是在講中臺這個產(chǎn)品的能力)。所以講能力是講給架構(gòu)的使用者或者其他想了解的人來聽的。

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

是指架構(gòu)內(nèi)模塊的職責，用來指導開發(fā)，比如中臺研發(fā)的同學，應(yīng)該講架構(gòu)的職責，依賴，約束。所以講職責是講給研發(fā)的同學，講給域內(nèi)的架構(gòu)師，講給域內(nèi)的管理者來聽的，總的來說就是講給架構(gòu)的實現(xiàn)者來說的。

簡單來說就是：能力是指產(chǎn)品的能力，職責是指架構(gòu)內(nèi)部的職責。如果架構(gòu)本身也是一個產(chǎn)品需對外輸出(如中臺，或者其他技術(shù)框架作為產(chǎn)品輸出)，則對外輸出時，我們應(yīng)該講這個技術(shù)產(chǎn)品的能力(這個時候技術(shù)的同學也就開始講能力了)。所以當我們討論問題的時候，如果有的人在談產(chǎn)品能力，有人在談架構(gòu)內(nèi)部職責，那么顯然已經(jīng)不是在討論同一個話題了，請大家務(wù)必注意區(qū)分這種情況，差之毫厘，謬以千里，雞同鴨講啊。

比如說兩個模塊 A 和 B，職責不一樣，但是依賴了相同的二方庫。那我們不能說某個職責在這個二方庫里。這個二方庫作為某個獨立的技術(shù)小產(chǎn)品，提供了某些能力。但是履行職責的還是 A 模塊或者 B 模塊。

1.5 應(yīng)用邏輯架構(gòu)的地位

正如前面我們描述的架構(gòu)分類所描述，有些架構(gòu)和具體業(yè)務(wù)是無關(guān)的，有些架構(gòu)是和具體業(yè)務(wù)息息相關(guān)的，比如說應(yīng)用邏輯架構(gòu)就是和業(yè)務(wù)息息相關(guān)，它來源于業(yè)務(wù)的抽象，甚至我們可以說：它是業(yè)務(wù)線技術(shù)架構(gòu)設(shè)計中第一份產(chǎn)出。

既然他是首要的產(chǎn)出，我們就必須要考慮應(yīng)用邏輯架構(gòu)中應(yīng)該包含的三類主題：

• 模塊

• 依賴

• 約束

絕大部分的架構(gòu)問題都可以歸納成這三類主題，這些主題包含哪些內(nèi)容呢?這就是本文接下來要介紹的內(nèi)容，應(yīng)用邏輯架構(gòu)的設(shè)計不需要拍腦袋，是通過科學的方法體系推導出來的。

二、架構(gòu)的兩種推導思路

架構(gòu)的產(chǎn)出總的來說有兩種方式，一種是自頂向下的方式來推導架構(gòu)，一種是自底向上的推導方式，而且兩種方式往往是相互結(jié)合來產(chǎn)出最合適的結(jié)果。而在業(yè)務(wù)線的同學，可能接觸最多的是自底向上的推導的方式，自底向上的推導的方式也是本文中要重點講解的架構(gòu)推導方式。

2.1 自頂向下的架構(gòu)推導

自頂向下的推導的關(guān)鍵問題在問題定義，如果問題沒有被準確的定義，那么自頂向下就無法推導出正確的結(jié)果。假設(shè)問題被準確的定義了，如何自頂向下推導呢?

2.2 自底向上的架構(gòu)推導

我們在業(yè)務(wù)線做開發(fā)的同學，每天肯定跟很多需求打交道，這些需求哪里來的?基本上有這三種產(chǎn)出：

有些是來自產(chǎn)品方一拍腦袋產(chǎn)生的靈感
有些是對數(shù)據(jù)進行了詳細的分析產(chǎn)出的產(chǎn)品策略
有些是當前產(chǎn)品中暴露的一個個問題

產(chǎn)品方的這些詳細的需求來了之后，我們是如何應(yīng)對的呢?我們首先和產(chǎn)品方一起討論產(chǎn)品方案的合理性，在產(chǎn)品方案合理的基礎(chǔ)上，我們來開始識別用例，開始了一系列軟件工程領(lǐng)域方面的措施。其整體過程如下圖所示：

自底向上推導邏輯架構(gòu)就是最右邊代表的那條曲線。

這里基本上就是本文接下來要重點闡述的：如何自底向上推導應(yīng)用邏輯架構(gòu)，這個過程就是一個抽象和架構(gòu)的過程。

那么我們從整體方法論的介紹開始，采用總分總的結(jié)構(gòu)，下面這張圖就是應(yīng)用邏輯架構(gòu)自底向上的推導路徑，這個推導路徑是有序的，每個步驟都包含了大量的操作技巧，前一步做好，后一步才有可能得出正確的結(jié)果。

這張圖中有幾個重點：

1)軟件研發(fā)分成了兩個階段：

分析階段，也是我們常說的問題空間領(lǐng)域建模，關(guān)鍵的一步是業(yè)務(wù)概念模型的輸出，而業(yè)務(wù)概念模型輸出的前置條件是從需求中分解出合理的用例集合。
設(shè)計階段，也是我們常說的解決方案空間建模，以及應(yīng)用邏輯架構(gòu)。

2)圖中存在了箭頭這個東西，說明了我們做架構(gòu)推導的主要的思維路徑，也說明做架構(gòu)不需要拍腦袋，都是根據(jù)嚴密的邏輯推導出來的。

這個嚴密邏輯基本是一個自底向上的推導過程，底層的模型是通過建模方法演繹出來，邏輯架構(gòu)中的各個模塊是通過歸納的方法推導出來。那么：

什么地方應(yīng)該用演繹，什么地方應(yīng)該用歸納呢?
使用演繹的時候應(yīng)該使用何種具體方法呢?
使用歸納的時候應(yīng)該使用何種具體方法呢?

我們再留一個懸念，后面再講。

不管是演繹還是歸納，都是抽象工作的一部分，而且都需要素材，這里的素材就是我們對需求，對業(yè)務(wù)的理解，以及對技術(shù)的深度廣度的把握。沒有素材，方法論掌握再好也得不出結(jié)果。

素材哪里來呢?

業(yè)務(wù)素材的來源大部分是你需要解決問題所在的領(lǐng)域，比如我們在電商領(lǐng)域，那么我們就要多搜集電商領(lǐng)域的業(yè)務(wù)知識。如果我們在數(shù)據(jù)領(lǐng)域，自然要多搜集數(shù)據(jù)業(yè)務(wù)的相關(guān)知識，以及我們前文中講到的技術(shù)類的相關(guān)知識。

而技術(shù)素材是要求我們在技術(shù)領(lǐng)域不斷的鉆研，不斷的擴展邊界，深度不斷增加，廣度也不斷增加。所以對于架構(gòu)師來說計算機科學與技術(shù)是絕對要不斷精進的。

2.3 兩個方法的區(qū)別

自頂向下推導的一個前置條件就是你需要知道豬長什么樣，在架構(gòu)上就是你需要知道這個架構(gòu)的原來是是什么樣子的，解決什么問題的。如果都不知道豬長什么樣，那么就無從判斷豬是不是適合當寵物了。此處需要有一定的業(yè)務(wù)領(lǐng)域理解力和領(lǐng)域經(jīng)驗(包含：客戶的問題和痛點是什么，怎么分析出來的，當前的架構(gòu)方案是什么，當前的架構(gòu)方案是如何解決這個問題的，未來的架構(gòu)方案如何更好的解決這個問題)。

而自底向上推導則沒有這個問題，因為是看著豬來做推導的，知道豬的細節(jié)，這個細節(jié)的特點如何演繹，如何歸納，最后得出結(jié)論。

所以當我們不熟悉一個大的業(yè)務(wù)的時候，我們自頂向下推導架構(gòu)的難度是極大的，幾乎不能完成。不了解業(yè)務(wù)或技術(shù)情況時定義出來的問題也未必是一個被正確定義的問題，容易給人造成一個印象：瞎指揮。

這個時候如何在沒有知識背景的情況下快速落地就得自底向上的來推導架構(gòu)。在自底向上的過程中慢慢熟悉業(yè)務(wù)。

但是如果工作中每每都是純粹的自底向上的推導架構(gòu)，是無法幫助我們來做技術(shù)的前瞻性布局的，此時架構(gòu)師的成長就遇到的瓶頸，所以此時又要使用自頂向下的架構(gòu)推導方式。

綜上所述，不管是自底向上，還是自頂向下，都是架構(gòu)師需要掌握的技能。

三、自底向上的架構(gòu)方法：業(yè)務(wù)概念架構(gòu)推導

這部分內(nèi)容，我在 ICBU，村淘，一達通，菜鳥，AE 現(xiàn)場分享過。尤其是在 AE，一達通和菜鳥，相關(guān)的同學都拿出了當時的糾結(jié)大家很久的難題，我們一起使用了這樣的方法很快就分析出了業(yè)務(wù)概念模型，并且對模塊進行了簡要的劃分，形成概要的業(yè)務(wù)概念架構(gòu)。經(jīng)過大量的實戰(zhàn)，效果是非常明顯的。

3.1 模型的 3 個層次

在這里，我把一些常見的概念集中起來，便于大家統(tǒng)一概念：

1)業(yè)務(wù)概念模型，問題空間領(lǐng)域模型，信息模型是同樣的意思，這個層次上的實體我們稱之為概念實體，這部分內(nèi)容是用在需求和業(yè)務(wù)分析上的，討論業(yè)務(wù)概念模型時完全不需要考慮軟件的實現(xiàn)，這個過程是一個分析過程，即使不做軟件研發(fā)，做其他的研發(fā)，類似的分析過程也應(yīng)該是有的。

2)系統(tǒng)模型，解決方案空間領(lǐng)域模型，邏輯模型是同樣的意思，這個層次上的實體，我們稱之為系統(tǒng)實體，或者邏輯實體，就是各種類，這個是用在軟件設(shè)計和軟件研發(fā)上的。

3)存儲模型，數(shù)據(jù)模型，物理模型，在這里也是同樣的意思，這個層次上的實體，我們稱之為數(shù)據(jù)實體，或者物理實體，也是用在軟件設(shè)計上。

這 3 個層次其實是從 3 個角度在看待問題，他們之間是自上而下的轉(zhuǎn)換的關(guān)系，這里尤其要注意的兩個詞是：邏輯的，順序的推導。

這些不同層次的模型是應(yīng)用邏輯架構(gòu)的基礎(chǔ)!!!

3.2 模型的推導

3.2.1 用例集合推導概念模型

根據(jù)用例集合推導業(yè)務(wù)概念模型
根據(jù)用例中的動詞和量詞推導業(yè)務(wù)概念模型的關(guān)聯(lián)關(guān)系
在特定的邊界內(nèi)根據(jù)模型的職責歸納子域

重要!重要!重要!這里業(yè)務(wù)概念模型如果沒有分析正確，那么下面要搞清楚是不容易的，這個分析部分是軟件邏輯架構(gòu)設(shè)計的基礎(chǔ)。

這個環(huán)節(jié)需要我們理解業(yè)務(wù)，更需要我們掌握問題空間建模這一嚴謹?shù)姆椒ㄕ摚@樣我們才能推導出合理的模型，整個過程是非常嚴謹?shù)模浅７线壿嫷摹?/p>

我在各 BU 分享現(xiàn)場做的多次實戰(zhàn)演練之所以能成功的快速幫助同學們梳理出前面花一兩個月都沒有理出的模型，完全是因為于現(xiàn)場的同學對業(yè)務(wù)的理解(因為討論之前我完全沒有了解過對方的業(yè)務(wù))和這套方法論(隱含在我的提問方式中)。所以說對業(yè)務(wù)的理解和方法論，兩者缺一不可。

3.2.2 對業(yè)務(wù)概念模型進行歸納

在模型產(chǎn)出之后，我們要對模型進行歸納。

什么叫歸納?

歸納的意思是將所有的結(jié)果和想法合并，變成一種思維概念。或者讓某個模型歸屬于某個已經(jīng)存在的思維概念。且這些模型或者模塊的職責不能超越這個高層次思維概念的邊界。

為什么要歸納?

其實是為了保證相近的職責模型聚攏在一起從而保證職責的高內(nèi)聚，同時明確出來的兩個子域的邊界，保證模塊和模塊之間的低耦合。

對業(yè)務(wù)概念模型的歸納有助于做業(yè)務(wù)需求分析時判斷高內(nèi)聚和低耦合，而且在系統(tǒng)模型上，對系統(tǒng)模型進行分類也有助于做應(yīng)用邏輯架構(gòu)中模塊的高內(nèi)聚和低耦合，但是應(yīng)用邏輯架構(gòu)的不止高內(nèi)聚和低耦合，還有其他讓職責單一的方法，這些后面的章節(jié)會做介紹。

3.2.3 按職責來進行歸納

接下來我們來講講業(yè)務(wù)概念模型到業(yè)務(wù)概念架構(gòu)判斷方法：

1)通過名詞定義來進行歸納思維概念

如果多個模型都在圍繞某個名詞，那么我們傾向?qū)⑦@個名詞提煉出來。產(chǎn)品在設(shè)計時，基本上我們已經(jīng)能夠得一個粗略的業(yè)務(wù)模塊劃分，但是這個粗略的劃分是不一定是合理：

一是有可能我們的理解是不到位的，導致用錯了名詞，這個我們前面的文章中也提到過了。
二是這個結(jié)果也只是一個粗略的結(jié)果，需要進一步精化。

2)通過內(nèi)聚的度量公式來進行歸納

業(yè)務(wù)模型圖中，模型和模型連線(連線就是模型和模型連接線)數(shù)量除以模型的梳理得到的值比較大的，那么我們可以看做是內(nèi)聚，這些連線比較緊密我們趨向?qū)⑵浞诺揭粋€模塊中，連線不是那么密切的，我們趨向于將它們放置在不同的模塊中。然后我們再觀察連線數(shù) / 模型數(shù) 觀察內(nèi)聚度量是高了還是低了，通過這樣的方式歸納完成之后，我們再來通過度量公式來度量各模塊的內(nèi)聚和耦合程度。

3)其他歸納方式

如果我們劃分出了基本模塊，發(fā)現(xiàn)還有一些模型不確定應(yīng)該放到哪些模塊中，我們還可以使用創(chuàng)建者原則和信息專家原則來判斷應(yīng)該將該模型歸納如哪個模塊。

比如說，對存儲系統(tǒng)進行系統(tǒng)建模，表和字段的關(guān)系在業(yè)務(wù)概念模型中是1對n的關(guān)系(在系統(tǒng)模型中是組合關(guān)系，強生命周期依賴，但是這里我們還沒有到討論應(yīng)用邏輯架構(gòu)的時候，只是在推導業(yè)務(wù)概念架構(gòu))，此時將字段放到另外一個模塊顯然不合適，原因是根據(jù)創(chuàng)建者原則。

當我們不清楚把字段模型放到哪個模塊的時候，我們可以看看字段這個模型是由誰創(chuàng)建的。

根據(jù)這條原則顯然這里是表創(chuàng)建了字段，沒有表對象，就沒有字段對象，所以根據(jù)這條原則，我們就傾向于把字段模型放到表所在的模塊中。

重點：失去了最底層合理且正確的演繹，上層的歸納掌握的再好，也很難得出合理的結(jié)果。

我們來看看歸納之后的效果示意圖：

圖中的 A1，A2，A3，A4 之類是示意圖，表示 A 模塊內(nèi)部還存在子模塊，當然我們其實是先推導出子模塊，然后對子模塊再次進行高級別歸納，形成父模塊。

父模塊層級再進行歸納，就形成了祖父模塊，或者再向上形成曾祖父模塊等等。粒度越大的模塊，一般都對應(yīng)更大的組織，越存在跨團隊溝通，所以劃清邊界的要求就越高。

3.3 業(yè)務(wù)流程

除了業(yè)務(wù)模型之外，業(yè)務(wù)流程也是我們需要總結(jié)并明確的地方，這個地方主要明確的就是邊界和異常分支等等，尤其是異常分支非常重要，很多業(yè)務(wù)方案的設(shè)計中對異常分支的考量是不重復(fù)的，這需要工程師對業(yè)務(wù)方案提出挑戰(zhàn)，以明確業(yè)務(wù)方案中的各種流程的異常分支。

3.4 業(yè)務(wù)概念架構(gòu)總結(jié)

我們工作中常見的推導有兩種方式，一種是自頂向下推導，一種是自底向上推導，顯然，兩種推導使用的方法是不一樣的。細心的讀者會發(fā)現(xiàn)，其實我們剛剛說的問題空間領(lǐng)域模型和邊界分析這套方法就是自底向上的演繹和歸納方法。

四、基礎(chǔ)邏輯架構(gòu)推導(軟件設(shè)計階段)

前面我們講到了業(yè)務(wù)分析階段，也是問題空間建模和問題空間業(yè)務(wù)概念架構(gòu)梳理，業(yè)務(wù)分析階段和軟件沒有任何關(guān)系。但本文中它是軟件設(shè)計的前置條件，沒有 get 到點的同學，請務(wù)必再把前一章仔細閱讀。

接下來我們來講講軟件設(shè)計階段我們需要產(chǎn)出的應(yīng)用邏輯架構(gòu)。

4.1 再談邏輯架構(gòu)特性

文章開頭講到了邏輯架構(gòu)的相關(guān)特點，我們回顧一下：

應(yīng)用邏輯架構(gòu)的作用：我們把前面那個例子再搬過來：如果拿汽車舉例，那就是發(fā)動機模塊中包含了哪些子模塊(活塞，曲軸，連桿，缸體，缸蓋，等等)發(fā)動機模塊和變速箱模塊之間的關(guān)聯(lián)關(guān)系是什么，和底盤的關(guān)聯(lián)關(guān)系是什么，發(fā)動機，底盤，變速箱，電子系統(tǒng)在整輛汽車中的職責，關(guān)系，約束是什么。這些都是用來指導汽車研發(fā)的。而不是指導用戶如何使用這輛汽車的。
目的：所以系統(tǒng)模型和應(yīng)用邏輯架構(gòu)都是用在軟件設(shè)計階段，其目的是用來指導軟件的研發(fā)。
受眾：邏輯架構(gòu)的受眾有哪些呢?一般是這些人：研發(fā)人員，各層級架構(gòu)師，各層級技術(shù)管理者，總的來說他們都是架構(gòu)的設(shè)計者和實現(xiàn)者。

這里還是請大家務(wù)必要跟產(chǎn)品功能架構(gòu)區(qū)分開來，它們的受眾和目標是不一樣的。

4.2 基礎(chǔ)邏輯架構(gòu)的推導概要

在文章開頭的圖中，我們講到應(yīng)用邏輯架構(gòu)來源于系統(tǒng)模型，數(shù)據(jù)模型，業(yè)務(wù)概念架構(gòu)，還有流程，如下圖所示。

接下來，我們分別從三個角度來闡述邏輯架構(gòu)的生成：

業(yè)務(wù)概念架構(gòu)
模型(系統(tǒng)模型和數(shù)據(jù)模型)
流程(系統(tǒng)調(diào)用流和數(shù)據(jù)流)

看到很多同學畫的圖沒有區(qū)分出調(diào)用流和數(shù)據(jù)流，經(jīng)常造成誤解，造成溝通效率下降，甚至不能夠準確的說明問題。所以在畫圖的時候，一定要注意區(qū)分調(diào)用流和數(shù)據(jù)流。

接下來就根據(jù)業(yè)務(wù)概念架構(gòu)和系統(tǒng)模型及流程來推導一下應(yīng)用架構(gòu)(邏輯架構(gòu))。我們來看一下一個簡單的邏輯架構(gòu)構(gòu)成的 gif 示意圖：

從這張圖中，我們可以看出應(yīng)用邏輯架構(gòu)是如何一步步被構(gòu)成的，整個過程存在以下關(guān)鍵點：

1)在業(yè)務(wù)概念架構(gòu)的基礎(chǔ)上推演應(yīng)用邏輯架構(gòu)。

2)根據(jù)流程和系統(tǒng)模型來完善應(yīng)用邏輯架構(gòu)。

3)橫向提煉模塊的問題：要實現(xiàn)業(yè)務(wù)模塊，需要什么非業(yè)務(wù)模塊的支撐，比如監(jiān)控，報警，配置等等，而這部分內(nèi)容往往還是可復(fù)用的。在上述動畫中，可以理解成移動到最右側(cè)的部分，當然可以移動到左側(cè)，只是動畫中沒有體現(xiàn)出來。

4)縱向提煉模塊問題：有類似職責的模塊在技術(shù)實現(xiàn)上是否可以提煉成可復(fù)用內(nèi)容，提煉的結(jié)果可能是：

獨立的服務(wù)復(fù)用，在上述動畫中，可以理解成最下方。
或者二方庫復(fù)用，在上述動畫中，可以理解成最左或者最右側(cè)。
等

5)還有一些模塊是為了支撐性能或者穩(wěn)定性的，并非是從業(yè)務(wù)概念模型提煉而來，如圖中深藍色的模塊。

最終，出現(xiàn)的邏輯架構(gòu)是分層的和分片的邏輯架構(gòu)，下面我們來一步步闡述這個過程。

4.3 根據(jù)業(yè)務(wù)概念架構(gòu)推演

業(yè)務(wù)概念架構(gòu)圖產(chǎn)出之后，基本上，我們邏輯架構(gòu)的初步模型就具備了。所以我們可以理解成，第一步就是把業(yè)務(wù)概念架構(gòu)直接先搬到應(yīng)用邏輯架構(gòu)中來，此處就不用多闡述了。

啰嗦兩句：尤其是較為頂層的粗粒度業(yè)務(wù)架構(gòu)，一個是自頂向下分解得來，一個是自底向上演繹和歸納得來。而自頂向下分解尤其考驗人對業(yè)務(wù)的理解能力，如果對業(yè)務(wù)理解不透徹，那很難產(chǎn)出合理的粗粒度業(yè)務(wù)概念架構(gòu)。

4.4 根據(jù)系統(tǒng)流程進行推演模塊

當業(yè)務(wù)概念架構(gòu)產(chǎn)出之后，邏輯架構(gòu)的骨架初成，接下來就是在這個框架上去填充內(nèi)容。第一步就是根據(jù)流程來進行模塊劃分。

總結(jié)一下，這里的方法就是，先根據(jù)業(yè)務(wù)流程，分解出系統(tǒng)時序圖，根據(jù)時序圖開始對模塊進行歸納，從而得到粒度更大的模塊。

這是粒度比較細的根據(jù)流程劃分模塊的案例，在粒度更大的流程，此方法同樣適用，看大家是工作在何種粒度上。

通過流程來進行推導是我們?nèi)粘９ぷ鞅夭豢缮俚囊徊糠郑绕洚敽芏鄨鼍暗牧鞒叹哂袠I(yè)務(wù)共同點時，那么可以考慮提煉出這些業(yè)務(wù)共同點，以提升研發(fā)的效率。

4.5 非業(yè)務(wù)線系統(tǒng)根據(jù)流程推導模塊案例

除了對流程進行歸納之外，我們還可以對系統(tǒng)模型進行歸納。我們知道，業(yè)務(wù)概念模型一般可以直接轉(zhuǎn)換為系統(tǒng)模型，但是系統(tǒng)模型并不只是業(yè)務(wù)領(lǐng)域相關(guān)的模型，比如查詢模型是一個經(jīng)常出現(xiàn)的，這在 OLTP 的場景十分常見，而在 OLAP 的場景簡直就是頂梁柱。非常常見的就是 SQL parser 模塊，下圖是 spark 體系中 SQL SQL 的主要流程和對應(yīng)的模型，根據(jù)這個模型我們基本上也可以梳理出模塊：

根據(jù)這個流程，我們發(fā)現(xiàn)了什么?我們發(fā)現(xiàn)了 spark 中是這樣分模塊的(這里面的模塊已經(jīng)落地成 package 了)：

所以說按照業(yè)務(wù)流程轉(zhuǎn)換成的系統(tǒng)流程來推導模塊是非常重要的手段。

除此之外需要還需要強調(diào)的是，流程和模塊一樣，也是有粒度的，相同粒度的流程節(jié)點放在一起才更加容易推導出合理的架構(gòu)模塊。至于什么叫相同粒度，請參考一下《金字塔原理》。

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

4.6 根據(jù)性能 & 穩(wěn)定性 & 成本等進行提煉模塊

前面講的都是從業(yè)務(wù)的角度來闡述架構(gòu)的推導，接下來我們從計算機科學與技術(shù)的角度來闡述一下這些非功能性模塊的推導，這里拿性能來舉個例子吧。

數(shù)據(jù)分析的報表場景降低 RT 的方案

在一些數(shù)據(jù)分析產(chǎn)品中，績效監(jiān)控及報表展示是一個非常重要的場景，這個場景下的數(shù)據(jù)量是比較大的，為了降低 RT，我們不得不通過 ETL 對數(shù)據(jù)進行預(yù)計算，將原有的大表清洗成聚合之后的小表，以加快查詢的速度。這樣做的缺點是每次進行報表的修改，就要進行相關(guān)的ETL邏輯，高時間和人力成本，高性能。

為了把高時間和人力成本 & 高性能轉(zhuǎn)換成低成本&高性能，我們需要把人工操作轉(zhuǎn)換成自動操作，把 ETL 的過程去除。

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

第二個選擇是根據(jù)報表的定義，自動的將判斷出用戶需要查詢什么結(jié)果，將查詢結(jié)果提前計算出來，然后只把這些少量的預(yù)計算后的結(jié)果導入到 ROLAP 引擎中(具體請參考 Apache 開源項目 Kylin)。然后在報表的場景下，查詢的 RT 下降到了百毫秒級。

顯然我們要實現(xiàn)第二種方式，這個時候在業(yè)務(wù)功能沒有增加的情況下，我們必須要增加一個模塊，在我們的產(chǎn)品中，我們稱之為 intelligent cube，因為我們這里引入了機器學習算法對 cube 的構(gòu)建進行了預(yù)測，無需或者只需非常少量的人為參與。

最后導致邏輯架構(gòu)中有部分是來自業(yè)務(wù)概念架構(gòu)推導而來，有部分是系統(tǒng)流程推導而來，有部分是因為性能 & 成本的需要產(chǎn)生的設(shè)計。

注意：理論上來講，邏輯架構(gòu)上需要指出模塊之間的依賴關(guān)系，只是如果這樣，不是特別美觀，所以就根據(jù)上下和左右的位置來大概描述模塊之間的關(guān)系了。

這兩個案例基本可以說明，根據(jù)性能 & 成本 & 穩(wěn)定性推導出來的模塊也是邏輯架構(gòu)組成的重要部分。

但是這個還只是一個場景一個場景來解決 RT 問題，雖然 icube 自己內(nèi)部是有個體系的，但是通過這樣的方式來解決 RT 問題對于整個架構(gòu)來說也是自底向上構(gòu)建的一個環(huán)節(jié)。在下一篇文章中，我們將會闡述相同的案例，但是思路是自頂向下來構(gòu)建性能領(lǐng)域的體系化架構(gòu)。同樣一個事情，用不同的思路來做，對總目標的幫助是不一樣的，而且兩個方法是互補的，誰都少不了。

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

看上去我們都已經(jīng)知道了系統(tǒng)中有不少類似的純技術(shù)相關(guān)的模塊，但是這些模塊內(nèi)部是如何設(shè)計出來的呢?

一般來說有如下方法幫助我們做這些模塊的內(nèi)部設(shè)計：

1)調(diào)查業(yè)界的開源技術(shù)類產(chǎn)品中是否有類似功能的，比如預(yù)計算在業(yè)界有 kylin，而星環(huán)等專業(yè)大數(shù)據(jù)公司也都有自己的 cube 預(yù)計算產(chǎn)品。

2)查閱業(yè)界相關(guān)的論文，比如說在預(yù)計算領(lǐng)域就已經(jīng)研究了幾十年，計算機發(fā)展的不同階段有不同的論文，網(wǎng)上一搜一大堆，不斷研究，必對工作有幫助。

3)多關(guān)注業(yè)界的牛人，看看他們在想什么，說什么，參加參加相關(guān)的會議。

4)自己通過邏輯和數(shù)據(jù)結(jié)構(gòu) & 算法推導出來。

如果每次都只通過自己的邏輯和自己已經(jīng)掌握的知識來進行方案的推導是不夠的，一個是我們的技能有時候和事情是不匹配的，但是我們往往不知道這樣的事實的存在，所以此時一定要虛心學習，請教他人，擴展自己的知識邊界，才能做出更好的方案和技術(shù)決策。

4.7 應(yīng)用邏輯架構(gòu)推導小結(jié)

根據(jù)上文所述，基本上應(yīng)用邏輯架構(gòu)的推導有 4 個子路徑，他們分別是：