如何畫好一張架構(gòu)圖？（內(nèi)含知識圖譜）

關(guān)于核心實體的抽取，這里的關(guān)鍵問題是：哪些是實體？如何判斷核心實體？如何抽??？抽取后的結(jié)果是什么樣的？很難用一種方法論的形式去描述，我也沒有完全形成我自己一成不變的方法論，但是我覺得如下三種方式可以供大家參考。

• 對象的分析方法

實體（Entity）：客觀存在并可相互區(qū)別的事物稱之為實體。實體可以是具體的人、事、物,也可以是抽象的概念或聯(lián)系。

從這個概念理解，和我們面向?qū)ο笕f物兼對象的理解是基本一致的。所以實體的抽取也可以借鑒對象分析的方法：獨立、可抽象、有層次性、在單個層次上又具備原子性。如下圖是《Thinking in UML》中關(guān)于對象的分析方法。

• 用例分析的方法

通過從業(yè)務(wù)用例中，去提取其中的關(guān)鍵詞，不同的關(guān)鍵詞可能表達了實體、關(guān)系、屬性等等內(nèi)容，從而完成模型分析與建立。這里引用六銖老師在《問題空間領(lǐng)域模型基本抽象方法》中的的內(nèi)容，簡述如下：

一句完整的用例描述中，首先找名詞，以「主語」和「賓語」為主，這些名詞基本可以確定我們的實體；其次找形容詞，存在于「定語」和「狀語」中，找到形容詞基本可以確定對應(yīng)屬性的值；然后通過對用例的補充，細化，對 名詞進行定義，慢慢的，我們會得到我們的領(lǐng)域模型和對應(yīng)的屬性。最后通過動詞&形容詞（存在于【謂語】，【狀語】，【定語】）來確定他們之間的關(guān)聯(lián)關(guān)系。

• 問題分析的方法

這是《聊聊架構(gòu)》中提的方式，具體講就是通過尋找問題的主體，然后分析主體的生命周期，進而通過區(qū)分生命周期里的關(guān)鍵活動來聚焦主體的關(guān)鍵屬性和關(guān)鍵關(guān)系。推薦大家閱讀前 9 章的內(nèi)容，總計才 40 頁的內(nèi)容，可能會有所體會。這里舉一個書中的例子：

一個笑話：一位女士對老公說：把袋子里的土豆削一半下鍋；結(jié)果所有土豆都下鍋了，而且每個土豆被削了一半。

作者指出，這里其實就沒有清晰的設(shè)別主體，這個主體不單是土豆，而是隱含的人要吃土豆，包括人和土豆兩個實體，這兩個實體之間的關(guān)系就是要解決的業(yè)務(wù)場景：怎樣吃？如何吃？為什么吃？所以主體識別不清楚，可能會導(dǎo)致整體實現(xiàn)的偏離。當(dāng)然實際過程中不會犯這么愚蠢的錯誤，但是也側(cè)面說明核心實體的抽取是非常關(guān)鍵的。

終極武器 - 自己講給自己：

實際的業(yè)務(wù)開發(fā)中，往往一種業(yè)務(wù)設(shè)計實現(xiàn)要滿足上層N個業(yè)務(wù)場景，這其中有共性也有個性化訴求，這個過程中我們很容易被多場景之間的異同搞混亂，要么邏輯不清晰、要么過度設(shè)計、要么考慮不周。我觀察過很多同學(xué)包括我自己，在一定的業(yè)務(wù)復(fù)雜度時容易失去設(shè)計的焦點。我的做法與業(yè)務(wù)建模類似，一定要邏輯對照：在所有的設(shè)計/邏輯模糊的點，將所有已知場景 分別套入，自己講給自己。請注意這里是“分別套入”，在當(dāng)前的設(shè)計層次下一個場景驗證完再去驗證下一個場景，找出阻塞的、模糊的點，重新梳理再優(yōu)化設(shè)計。系統(tǒng)建模的結(jié)果指導(dǎo)我們軟件設(shè)計實現(xiàn)，所以一定要反復(fù)梳理打通，這個反復(fù)的過程其實也是提升架構(gòu)能力的過程，累積到一定程度就會自然通透。

回到開始的那個問題：

模是什么？通過上面業(yè)務(wù)建模和系統(tǒng)建模的描述，簡單來講模就是業(yè)務(wù)的映射，這個映射的結(jié)果是業(yè)務(wù)模型、概念模型或設(shè)計模型，但是所有的出發(fā)點都是業(yè)務(wù)需求：客戶是誰？核心訴求是什么？

如何建？上面通過業(yè)務(wù)建模和系統(tǒng)建模兩個維度，從個人實踐角度大概講了常規(guī)的套路，建模的本質(zhì)其實一個抽象的過程，但是上述業(yè)務(wù)和系統(tǒng)建模抽象的過程其實還有兩個問題并沒有完全說清楚：

• 業(yè)務(wù)建模中“把書讀薄”歸類匯總，建立「大局觀」，形成大圖，這里按什么維度去歸類？如何判斷歸類是正確的？

• 系統(tǒng)建模中“剝洋蔥”怎么拆？按什么拆？上述架構(gòu)圖中的層次、領(lǐng)域如何劃分層次？邊界在哪里？

說回抽象

Haskell 語言的設(shè)計者之一 Paul Hudak 曾說過一句略帶夸張的話：編程中最重要的三件事是： 抽象，抽象，抽象。

“abstraction, abstraction, abstraction”are the three most important things in programming.

如果要問程序員最重要的能力有哪些，我相信抽象一定是其中最重要的之一。那到底什么是抽象？

百度百科定義：

從具體事物抽出、概括出它們共同的方面、本質(zhì)屬性與關(guān)系等，而將個別的、非本質(zhì)的方面、屬性與關(guān)系舍棄，這種思維過程，稱為抽象。

如果更精煉的概括：抽象就是做減法和做除法。通過舍棄非本質(zhì)和無關(guān)緊要的部分，著眼于問題的本質(zhì)，去粗取精；通過透過現(xiàn)象看本質(zhì)，發(fā)現(xiàn)不同事物之間的共同之處，異中求同，同類歸并，也就是做除法。上文中建模過程是共性抽象，通過不斷的抽象達到某個狀態(tài)為止，我理解這個狀態(tài)沒有確定性的答案，核心就是滿足業(yè)務(wù)場景的需要，其實這背后也有一個邊界的問題。

1. 抽象的角度

生活中處處都是抽象，但是我們似乎少了為什么是這樣或那樣抽象的思考。抽象是有角度之分的。

生活中我們常常說“我的觀點是…”，其實這里的“觀點”就是一個角度問題，從一定的立場或角度出發(fā)，對事物或問題所持的看法。以生活中的常見的實物來說（如下圖），我們是否能快速的說出其中的相同點和不同點。

如圖中已經(jīng)標(biāo)注的，我們從功用的角度對它們定義了椅子、桌子、凳子和柜子這樣的區(qū)分，但顯然很有很多很多角度，比如：物料、文字、高矮等等維度，從不同維度看過去，會有完全不同的相同點和不同點表述，所以，本質(zhì)是什么？本質(zhì)是：

• 抽象角度其實也是分類的角度，角度不同，會導(dǎo)致完全不同建模方向和結(jié)果；

• 抽象的角度就是建模的方向和目的（“屁股決定腦袋”）。

重新回到我們前邊的兩個問題，業(yè)務(wù)建模中我們談到了歸類，按什么去歸類，答案呼之欲出，按我們的業(yè)務(wù)流程去歸類、按客戶的角色去歸類，又回到了那個最初始的問題：客戶是誰？核心訴求是什么？

同時，上文中我們提到，模是業(yè)務(wù)的映射，基于對抽象的理解，我們可以進一步展開： 模是在確定抽象角度下的業(yè)務(wù)映射。

2. 抽象的層次

Wikipedia 關(guān)于抽象的定義中有一個關(guān)于報紙的例子：

1. 我的 5 月 18 日的《舊金山紀(jì)事報》
2. 5 月 18 日的《舊金山紀(jì)事報》
3. 《舊金山紀(jì)事報》
4. 一份報紙
5. 一個出版品

這五句話中，我們可以感受到抽象的層次，抽象層次越高，細節(jié)越少，普適性越強。再比如下圖中關(guān)于網(wǎng)絡(luò)模型的抽象，關(guān)于操作系統(tǒng)內(nèi)核的抽象，我們可以明顯的看到不同層次的抽象，就是過濾不同的信息，最終留下來的信息才是當(dāng)前抽象層次所需要的信息。從系統(tǒng)設(shè)計實現(xiàn)上來說， 抽象層次越高，越接近設(shè)計，越遠離實現(xiàn)，同時抽象的模型越不受細節(jié)的羈絆，穩(wěn)定性越高，普適性越強，可重用性就越高。

那么這里抽象的劃分層次的依據(jù)是什么？原則又是什么？我的經(jīng)驗是， 劃分抽象層次的依據(jù)主要包含兩個：

• 以抽象角度分層（可能一層是多角度的聚合）
• 面對變化分層（用層次隔離變化）

其實這個也不能完全解釋如何分層，原則是什么？我覺得這是幾個 最通用的原則：

• 公用的往下走
• 個性的往上走
• 下層可以獨立于上層存在
• 控制下層的變化

考慮抽象層次的好處是不論在哪一個層次上，我們只需要面對有限的復(fù)雜度，從而專心考慮這個層次上的抽象是什么，要表達的信息是什么。

3. 抽象的邊界

除了角度、層次之外，我們還需要考慮的抽象的邊界。如果說層次考慮的是縱向維度的表達，那么邊界考慮的是橫向維度的表達。如何確定邊界， 一個總的原則是按照職責(zé)進行劃分，這里的職責(zé)其實也就是分工。一旦職責(zé)確定，我們在做建模分析時就不需要把整個業(yè)務(wù)大局放進來從頭到尾去分析一遍，我們只需要考慮當(dāng)前分工下的上游和下游即可，這樣的信息量大大減少，自然的我們面對的領(lǐng)域復(fù)雜度也會降低到一定程度。

如果一定要給出邊界的定義，我的理解是： 邊界是在確定抽象角度下，通過尋找核心的業(yè)務(wù)活動，抽取核心實體，進一步確定實體核心生命周期的結(jié)果?？赡苡幸稽c點繞，關(guān)鍵詞是：核心業(yè)務(wù)活動、核心實體、核心實體生命周期。

以現(xiàn)場娛樂行業(yè)為例，如下這張圖包含了最高抽象層次下業(yè)務(wù)的全生命周期，這個抽象層次下的主體是什么，我的理解是票，項目生產(chǎn)的結(jié)果是票，分銷或電商服務(wù)是對票的銷售，現(xiàn)場是對票的核驗，至此以票為核心實體的生命周期結(jié)束。

如果我們往下 Down 一層，從項目生產(chǎn)這一個業(yè)務(wù)活動去看，整個業(yè)務(wù)流程是這樣：

項目管理->場館座位分銷->票房預(yù)測->場次管理->配額管理->繪座->票房規(guī)劃

從生產(chǎn)這個視角去看，核心的實體不是票，而是場次（確定時間、確定地點、確定內(nèi)容的一場演出或賽事），所有的關(guān)鍵業(yè)務(wù)活動都是以場次為維度，生產(chǎn)領(lǐng)域里需要考慮的主要就是場次的核心生命周期。

所以，在不同的抽象角度、不同的抽象層次，根據(jù)分工的不同會有不同的核心業(yè)務(wù)活動、不同的核心實體、邊界的確定關(guān)鍵在尋找核心的生命周期。尋找生命周期的過程，就是發(fā)現(xiàn)內(nèi)聚的過程；將所有關(guān)于生命周期的業(yè)務(wù)活動累積，就可以提升領(lǐng)域或模塊的內(nèi)聚性。

4. 抽象的評估

前邊我們基本說清楚了抽象的角度、層次和邊界，從三個維度確定了抽象的結(jié)果。那么如何評估抽象結(jié)果的好壞呢？答案是“高內(nèi)聚，低耦合”，當(dāng)然還有更多的原則，但是單從實踐的角度，我覺得這是最最重要的。

· 耦合是軟件結(jié)構(gòu)中各模塊之間相互連接的一種度量；
· 內(nèi)聚是一個模塊內(nèi)部各成分之間相關(guān)聯(lián)程度的度量。

“高內(nèi)聚，低耦合”從內(nèi)部、外部兩個視角去評估抽象結(jié)果的好壞。這其中也有對應(yīng)的原則和方法論，常規(guī)的套路是：

• 每次從一個角度來切分，然后換多個角度來審視
• 通過組合、拆分來精化、優(yōu)化模型與設(shè)計（抽象的結(jié)果）
• 關(guān)鍵的審視點：耦合性：減少模塊間通信量；內(nèi)聚性：功能單一化；變化的隔離性：減少信息依賴，建隔離層、虛擬層。

5. 抽象的方法論（套路）

我想，至此，我們說清楚了前面的那兩個問題：

• 業(yè)務(wù)建模中“把書讀薄”歸類匯總，建立“大局觀”，形成大圖，這里按什么維度去歸類？如何判斷歸類是正確的？

• 系統(tǒng)建模中“剝洋蔥”怎么拆？按什么拆？上述架構(gòu)圖中的層次、領(lǐng)域如何劃分層次？邊界在哪里？

總結(jié)前面說的所有關(guān)于抽象的內(nèi)容，形成 抽象的方法論（套路）：

• 抽象有兩種方法，一種是自頂向下，另一種是自底向上；

• 業(yè)務(wù)建模，是從小到大，從局部到整體，自底向上的歸納、演繹的抽象過程；

• 系統(tǒng)建模，是從大到小，從整體到局部，自頂向下的拆解、切分的抽象過程；

• 但不絕對，自上而下和自下而上，往往在過程中是隨意切換的。

下面這張圖來自于《Thinking in UML》，我覺得這個循環(huán)的過程可以表達上面這四個點，供大家參考。

如何畫好一張架構(gòu)圖？

回到主題，如果上邊的問題說清楚了，接下來的事情就相對簡單了。對于架構(gòu)圖是什么這個問題，我們可以把之前的等式進行延展： 架構(gòu)圖 = 架構(gòu)的表達 = 架構(gòu)在不同抽象角度和不同抽象層次的表達，這是一個自然而然的過程。不是先有圖再有業(yè)務(wù)流程、系統(tǒng)設(shè)計和領(lǐng)域模型等，而是相反，用圖來表達抽象的思考和內(nèi)容。

那么架構(gòu)圖有什么用？給誰看？回答這個問題需要講清楚為什么要畫架構(gòu)圖，同時也需要考慮一個問題就是：架構(gòu)圖是不是越多越好，越詳細越好？

1. 畫架構(gòu)圖是為了什么？

A picture is worth a thousand words （一圖勝千言），從 Why 層面講，我覺得就是如下兩點：

• 解決溝通障礙：達成共識、減少歧義；

• 提升協(xié)作效率：團隊內(nèi)部和團隊之間的協(xié)作、溝通、愿景和指導(dǎo)。

但是上述兩點其實是非?；\統(tǒng)的信息，如果放在 What 層面，我們必須要考慮架構(gòu)圖面對的“客戶”，不同的客戶有不同的訴求（其實也就是角度和層次），在不同的抽象層次架構(gòu)圖所表達的信息內(nèi)容可以完全不一樣。以目前團隊做的事情為例，架構(gòu)圖的目標(biāo)客戶至少有幾類：

• 參與項目的各團隊各角色（業(yè)務(wù)、產(chǎn)品、開發(fā)、測試、安全、GOC）
• 項目之外的客戶（外部客戶，外部評審專家）
• 各層次 TL（匯報，跨 BU，跨團隊協(xié)作溝通）

所以畫架構(gòu)圖，我們必須首先明確溝通交流的目的和面向的客戶，只有明確了這兩個點才能更加有針對性的達成上邊所說的那兩點目標(biāo)：解決溝通障礙，提升協(xié)作效率。

2. 怎么畫？

1）先說分類

架構(gòu)圖分類，本質(zhì)上是從不同的視角，不同的抽象角度去看，作出清晰、簡化的描述，涵蓋特點方面忽略無關(guān)方面。

從業(yè)務(wù)應(yīng)用開發(fā)的維度，一般的抽象層次可以分為：

業(yè)務(wù)全域—>子域—>模塊—>子模塊—>包—>類—>方法

這其中：

• 較低層次的抽象：應(yīng)用內(nèi)部包圖、類圖；某個領(lǐng)域：實體圖、時序圖、狀態(tài)圖、用例圖等等；

• 較高層次的抽象：具有一定的復(fù)雜性，比如微服務(wù)架構(gòu)，系統(tǒng)間的交互圖，領(lǐng)域/子領(lǐng)域架構(gòu)圖，整個系統(tǒng)架構(gòu)圖等等。

當(dāng)然，還有很多其他的分類方式，比如：RUP 4+1，GOGAF9 等等分類方式。 單從實踐的角度，我覺得何種分類不是最重要的，最重要的是想清楚面向誰和解決什么訴求，然后思考架構(gòu)圖到底從哪個角度、哪個層次去抽象。我們目前所做的項目，有很時候要去和國外的業(yè)務(wù)專家、技術(shù)專家去溝通，大家也并沒有一個明確的標(biāo)準(zhǔn)定義，表述清楚問題，達成共識這是最最關(guān)鍵的，至于架構(gòu)圖的粒度、類別、內(nèi)容可以逐步的去完善，去粗取精，迭代優(yōu)化。

2）再說構(gòu)圖

構(gòu)圖的部分，我們大家都用 UML 畫過類圖，涉及泛化、聚合、組合、依賴等等關(guān)系，分別用不同的虛實線、箭頭樣式進行表達。所以畫架構(gòu)圖需要考慮架構(gòu)圖的組成元素，要保證符合一貫理解，架構(gòu)圖的組成元素可能涉及：

• 方框、各種形狀、虛實線、箭頭、顏色（不同顏色代表什么意思）和文字內(nèi)容；

• 虛實線表達什么？組件類型，模塊類型，層，服務(wù)，需要考慮是否已經(jīng)實現(xiàn)等？不同狀態(tài)的標(biāo)識怎么傳遞？

• 箭頭表達什么?數(shù)據(jù)流或關(guān)聯(lián)關(guān)系？

• 交互類型可以是同步或異步的；關(guān)聯(lián)類型可以是指依賴、繼承、實現(xiàn)。

構(gòu)圖最最重要的是需要考慮內(nèi)容術(shù)語一致性問題、碎片化問題、信息粒度大小的問題，以及圖表的外觀問題。

3. 如何評判架構(gòu)圖的好壞

架構(gòu)圖的好壞，我理解主要是兩個方向，一個是需要跳出圖本身去看，業(yè)務(wù)領(lǐng)域的抽象設(shè)計合理性，是否符合“高內(nèi)聚，低耦合”的要求，這個需要回到前文的業(yè)務(wù)建模、系統(tǒng)建模和抽象過程去尋找答案。另外一個方向是圖本身，以下幾個點供參考：

• 內(nèi)容術(shù)語一致、信息粒度大小一致，圖例清晰，顏色類型統(tǒng)一，美觀；

• 圖中的信息與相應(yīng)的抽象級別相關(guān)，且滿足利益相關(guān)者(合作方)的需求；

• 一張好的架構(gòu)圖不需要多余的文字解釋！受眾有沒有準(zhǔn)確接收到想傳遞的信息；如果它所導(dǎo)致的疑問比它能解釋的問題還要多，那么它就不是一張好的架構(gòu)圖；

• 架構(gòu)圖應(yīng)該幫助每個人看到大局，了解周圍的環(huán)境，適當(dāng)?shù)纳舷挛男畔ⅲ?/p>

• 架構(gòu)圖應(yīng)該避免“只見樹木，不見森林”。

但是，終歸還是那句話， “一張圖片勝過千言萬語”。不管好壞，不管是否美觀，人是視覺動物，用圖表達可以極大的提升溝通效率，先畫起來吧！

最后也聊聊架構(gòu)師

這是來自于阿白老師的文章《架構(gòu)師到底是做什么的？》，越是琢磨，越覺得深以為然。其中提到了好的架構(gòu)師的畫像和不好的畫像，如下圖，與大家共勉。

從我個人的成長經(jīng)歷看， 架構(gòu)師很重要的一點要學(xué)會“權(quán)衡”，既要兼顧當(dāng)下痛點也要符合未來一定時間的發(fā)展，既要保留未來的可擴展性也要避免過度設(shè)計。選擇什么樣的時間節(jié)點、什么樣的業(yè)務(wù)場景以及什么樣的架構(gòu)迭代策略至關(guān)重要，這些決策的關(guān)鍵在于判斷和取舍，需要結(jié)合深刻的業(yè)務(wù)思考乃至組織架構(gòu)去做權(quán)衡落地。一點點不算經(jīng)驗的經(jīng)驗：

1. 快速學(xué)習(xí)

快不是一個速度問題，也是一個判斷或者標(biāo)準(zhǔn)問題。面對一個全新業(yè)務(wù)場景，如何能夠識別20%的關(guān)鍵業(yè)務(wù)路徑，關(guān)鍵業(yè)務(wù)痛點，如何短時間把自己變成業(yè)務(wù)專家這是一個架構(gòu)師基本的素質(zhì)。我的一點經(jīng)驗就是要去「吸金式」的思考，帶著問題主動思考，客戶是誰？有什么訴求？需要解決什么樣的問題？我們能提供什么樣的價值？多問為什么？這也需要長時間的刻意訓(xùn)練。

2. 不要屁股決定腦袋

要跨角色、跨層級去看待業(yè)務(wù)問題，這個點容易陷入說教，說實話我自己做得也未必到位。但是時刻提醒自己的思考是否被局限，在哪一個維度，是 Have-do-be，還是 be-do-Have 等等；同時也不斷的在提醒自己永遠不要屁股決定腦袋。

3. 提升思考能力和對于技術(shù)原理或本質(zhì)的理解

我覺得這是最底層的能力，業(yè)務(wù)開發(fā)中我覺得最大的兩個難點：一是邏輯的復(fù)雜性，二是需求的變化性。我們不應(yīng)該大部分時間花在尋找解決方案上，而應(yīng)該花更多的時間在選擇解決方案上。這就要求我們對業(yè)務(wù)全局、行業(yè)深度、技術(shù)視野、技術(shù)深度、業(yè)務(wù)共性、個性特征等等形成自己的認知。權(quán)衡取舍，取什么舍什么？該怎么取怎么舍？那個度在哪里？唯有思考，自驅(qū)，累積和堅持，勇猛精進，志愿無倦。

最后的最后

希望這篇文章對大家有幫助，附上最初在考慮這個主題時的構(gòu)思過程及思考路徑，供大家參考。

參考文檔：

• 為什么我們需要架構(gòu)圖( https://new.qq.com/omn/20190131/20190131A16MWK.html)
• 軟件架構(gòu)圖的藝術(shù) ( https://www.infoq.cn/article/crafting-architectural-diagrams)
• 邏輯架構(gòu)和物理架構(gòu) ( https://www.cnblogs.com/dinglang/p/4565378.html)
• 一篇文章讀懂分層架構(gòu) ( https://zhuanlan.zhihu.com/p/40353581)
• TOGAF & RUP( https://www.ibm.com/developerworks/cn/rational/rationaledge/content/feb07/temnenco/index.html)
• 如何自底向上推導(dǎo)應(yīng)用邏輯架構(gòu)？+如何自頂向下構(gòu)建架構(gòu)？（節(jié)選）( https://developer.aliyun.com/article/727436)
• 《大象：Thinking in UML》
• 《聊聊架構(gòu)》

關(guān)注“阿里巴巴云原生”公眾號，回復(fù)“架構(gòu)”即可查看清晰知識大圖！

課程推薦

為了更多開發(fā)者能夠享受到 Serverless 帶來的紅利，這一次，我們集結(jié)了 10+ 位阿里巴巴 Serverless 領(lǐng)域技術(shù)專家，打造出最適合開發(fā)者入門的 Serverless 公開課，讓你即學(xué)即用，輕松擁抱云計算的新范式——Serverless。

點擊即可免費觀看課程： https://developer.aliyun.com/learning/roadmap/serverless

“ 阿里巴巴云原生關(guān)注微服務(wù)、Serverless、容器、Service Mesh 等技術(shù)領(lǐng)域、聚焦云原生流行技術(shù)趨勢、云原生大規(guī)模的落地實踐，做最懂云原生開發(fā)者的公眾號?！?/p>