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

阿里妹導(dǎo)讀：架構(gòu)圖是什么？為什么要畫架構(gòu)圖？如何畫？有哪些方法？本文從架構(gòu)的定義說(shuō)起，分享阿里文娛高級(jí)技術(shù)專家簫逸關(guān)于畫架構(gòu)圖多年的經(jīng)驗(yàn)總結(jié)，并對(duì)抽象這一概念進(jìn)行了深入地討論。較長(zhǎng)，同學(xué)們可收藏后再看。

文末福利：架構(gòu)師成長(zhǎng)秘籍。

什么是架構(gòu)圖？

如何畫好一張架構(gòu)圖，要做好這件事情首先要回答的就是什么是架構(gòu)圖。我們?nèi)粘９ぷ髦薪?jīng)常能看到各種各樣的架構(gòu)圖，而且經(jīng)常會(huì)發(fā)現(xiàn)大家對(duì)架構(gòu)圖的理解各有側(cè)重。深入追究到這個(gè)問(wèn)題，可能一下子還很難有一個(gè)具象的定義，如果我們把這個(gè)問(wèn)題進(jìn)行拆分（如下圖）理解起來(lái)就會(huì)容易一點(diǎn)。

• 
  

架構(gòu)圖 = 架構(gòu) + 圖

按照這個(gè)等式，我們可以把問(wèn)題轉(zhuǎn)換：

• 架構(gòu)是什么？
• 圖是什么？

圖是什么？這個(gè)比較容易回答，圖是一種信息的表達(dá)方式，所以架構(gòu)圖，即表達(dá)“架構(gòu)”的圖，也就是一種架構(gòu)的表達(dá)方式。也即：

• 
  

架構(gòu)圖 = 架構(gòu)的表達(dá) = 表達(dá)架構(gòu)的圖

按照這種思路我們需要回答：

• 什么是架構(gòu)？要表達(dá)的到底是什么？
• 如何畫好一張架構(gòu)圖？

接下來(lái)的內(nèi)容基本上就是按照這兩個(gè)維度來(lái)做分析。

什么是架構(gòu)？要表達(dá)的到底是什么？

Linus 03 年在聊到拆分和集成時(shí)有一個(gè)很好的描述：

I claim that you want to start communicating between independent modules no sooner than you absolutely HAVE to, and that you should avoid splitting things up until you really need to, because that communication complexity often swamps the complexity of the actual pieces involved in it.（讓我們認(rèn)識(shí)到一種現(xiàn)象，把復(fù)雜系統(tǒng)拆分成模塊，似乎并沒(méi)有降低整個(gè)系統(tǒng)的復(fù)雜度。它降低的只是子系統(tǒng)的復(fù)雜度。而整個(gè)系統(tǒng)的復(fù)雜度，反而會(huì)由于拆分后的模塊之間，不得不進(jìn)行交互，變得更加復(fù)雜。）

我理解這里描述的系統(tǒng)拆分就是架構(gòu)的過(guò)程，基本出發(fā)點(diǎn)是為了效率，通過(guò)架構(gòu)的合理拆分（無(wú)論是空間還是時(shí)間上的拆分），最終目的讓效率大化。那到底什么是架構(gòu)，其實(shí)沒(méi)有完全統(tǒng)一且明確的定義，如下三個(gè)定義可以參考。

在百度百科上的定義：

架構(gòu)，又名軟件架構(gòu)，是有關(guān)軟件整體結(jié)構(gòu)與組件的抽象描述，?于指導(dǎo)?型軟件系統(tǒng)各個(gè)方面的設(shè)計(jì)。

在 Wikipedia 上的定義：

Architecture is both the process and the product of planning, designing, and constructing buildings or any other structures.

ISO/IEC 42010:20072 中對(duì)架構(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.　

這三個(gè)定義也是見(jiàn)仁見(jiàn)智，但是我們基本可以得出：架構(gòu)體現(xiàn)的是整體結(jié)構(gòu)和組件之間的關(guān)系。

架構(gòu)的本質(zhì)

這里引用三個(gè)觀點(diǎn)來(lái)探討架構(gòu)的本質(zhì)：

• 架構(gòu)的本質(zhì)是為了管理復(fù)雜性。

• 架構(gòu)的本質(zhì)就是對(duì)系統(tǒng)進(jìn)行有序化重構(gòu)，不斷減少系統(tǒng)的“熵”，使系統(tǒng)不斷進(jìn)化。

• 架構(gòu)的本質(zhì)就是對(duì)系統(tǒng)進(jìn)行有序化重構(gòu)，以符合當(dāng)前業(yè)務(wù)的發(fā)展，并可以快速擴(kuò)展。

上述三個(gè)觀點(diǎn)提到的內(nèi)容，基本表達(dá)了架構(gòu)的核心目的：管理復(fù)雜性，效率大化。以及架構(gòu)的兩個(gè)主要變化來(lái)源：一個(gè)是以改善軟件質(zhì)量為目的的內(nèi)在結(jié)構(gòu)性變化；另外一個(gè)是以滿足客戶需求為目的的外在功能性變化。無(wú)論是何種變化，在我看來(lái)架構(gòu)都是在不斷的判斷和取舍，在業(yè)務(wù)需求和系統(tǒng)實(shí)現(xiàn)之間做權(quán)衡，從而來(lái)應(yīng)對(duì)未來(lái)變化的不確定性，如下圖可以比較粗淺直觀的表達(dá)這種理解。

要表達(dá)的是什么？

在 EA 架構(gòu)領(lǐng)域，有兩種常見(jiàn)架構(gòu)方法 RUP 和 TOGAF，這兩個(gè)框架也是我們常常了解架構(gòu)分類的兩個(gè)維度。從個(gè)人的角度，我自己覺(jué)得 TOGAF 的分類方式更加廣泛使用（如下右圖）。

結(jié)合日常的業(yè)務(wù)開(kāi)發(fā)，其實(shí)我們更多的是關(guān)注業(yè)務(wù)架構(gòu)和應(yīng)用架構(gòu)，所以把上邊的表達(dá)式進(jìn)一步的拆解，在回答如何畫好一張架構(gòu)圖之前，我們需要關(guān)注業(yè)務(wù)架構(gòu)和系統(tǒng)架構(gòu)，討論清楚如何進(jìn)行業(yè)務(wù)架構(gòu)和系統(tǒng)架構(gòu)。

架構(gòu)的過(guò)程其實(shí)就是建模的過(guò)程

我們都知道現(xiàn)實(shí)世界到軟件世界或者面向?qū)ο蟮氖澜绲倪^(guò)程，是一個(gè)不斷抽象的過(guò)程，這其中的方法就是不斷的建立模型。從現(xiàn)實(shí)世界到業(yè)務(wù)模型，從業(yè)務(wù)模型到概念模型，從概念模型到設(shè)計(jì)模型，通過(guò)不斷的抽象去粗取精，形成對(duì)現(xiàn)實(shí)世界的層層抽象，所以架構(gòu)的過(guò)程其實(shí)就是建模的過(guò)程。至此，我們有必要了解一下什么是建模。

百度百科定義：

建模就是建立模型，就是為了理解事物而對(duì)事物做出的一種抽象，是對(duì)事物的一種無(wú)歧義的書面描述。

《Thinking in UML》定義：

建模（Modeling），是指通過(guò)對(duì)客觀事物建立一種抽象的方法用以表征事物并獲得對(duì)事物本身的理解，同時(shí)把這種理解概念化，將這些邏輯概念組織起來(lái)，構(gòu)成一種對(duì)所觀察的對(duì)象的內(nèi)部結(jié)構(gòu)和工作原理的便于理解的表達(dá)。

從上述兩個(gè)定義上基本可以了解到建模就是抽象，對(duì)業(yè)務(wù)或現(xiàn)實(shí)世界的抽象，雖然不足以幫我們理解架構(gòu)本身，但是可以將我們上述關(guān)注的業(yè)務(wù)架構(gòu)和系統(tǒng)架構(gòu)進(jìn)一步向下 Down 一層，架構(gòu)的過(guò)程是建模的過(guò)程，我們轉(zhuǎn)換成兩個(gè)簡(jiǎn)單的問(wèn)題：模是什么？如何建？

模是什么？如何建？

這是兩個(gè)比較容易陷入理論性的問(wèn)題，我們跳出來(lái)從結(jié)果看過(guò)程。接下來(lái)通過(guò)已經(jīng)產(chǎn)出的一些架構(gòu)圖來(lái)反向看這些架構(gòu)圖是如何產(chǎn)出的，同時(shí)來(lái)回答這兩個(gè)問(wèn)題。

業(yè)務(wù)建模

回到當(dāng)下業(yè)務(wù)本身，對(duì)我而言也是全新的，在最初接觸的時(shí)候憑僅有的行業(yè)背景去理解，結(jié)合了大量的文檔閱讀最終產(chǎn)出了如下圖示的《業(yè)務(wù)核心流程圖》和《業(yè)務(wù)功能模塊圖》。這兩張圖基本上就涵蓋了所有的業(yè)務(wù)內(nèi)容。左邊的業(yè)務(wù)流程圖得到了這個(gè)行業(yè) 20 多年從業(yè)經(jīng)驗(yàn)專家認(rèn)可，他認(rèn)為這就是 20 多年所從事的業(yè)務(wù)內(nèi)容。

圖片源于網(wǎng)絡(luò)，為示意圖，侵刪

回溯整個(gè)過(guò)程，特別是左側(cè)的業(yè)務(wù)核心流程圖，今天創(chuàng)新互聯(lián)看這張流程圖很容易構(gòu)架起一個(gè)基本邏輯來(lái)，縱向是不同的業(yè)務(wù)角色和系統(tǒng)，橫向是時(shí)間的推進(jìn)，特別容易理解。但我想說(shuō)最開(kāi)始的理解和分析是極其耗時(shí)和壓力極大的過(guò)程。這個(gè)過(guò)程中我所用的方法就是：

• “把書讀厚”：大量的信息輸入，同時(shí)探求可能性。
• “把書讀薄”：歸類匯總，形成大圖。
• 邏輯對(duì)照，確保理解和分析的正確性。

1）把書讀厚

下圖基本涵蓋“把書讀厚”的過(guò)程，匯聚大量的文檔信息，嘗試用多維度去形成邏輯。這個(gè)維度可能是依據(jù)歷史經(jīng)驗(yàn)，也可能是依據(jù)文檔內(nèi)容，比如在形成業(yè)務(wù)大圖的過(guò)程中，我曾按可能的場(chǎng)景邏輯、可能的系統(tǒng)或領(lǐng)域邏輯分別把多個(gè)文檔中的內(nèi)容歸類，探求可能性。

這個(gè)過(guò)程會(huì)很枯燥，特別是涉及一些業(yè)務(wù)的術(shù)語(yǔ)內(nèi)容，理解起來(lái)就會(huì)很困難。我的方式就是把自己當(dāng)做一名“探索者”，如同我們玩游戲一樣，常常問(wèn)自己“我的游戲地圖全部點(diǎn)亮了嗎？”未必要照顧到所有細(xì)節(jié)，但是需要力求覆蓋整體內(nèi)容。仔細(xì)想想，似乎也和日常的讀書類似，這期間值得注意的是：

• 重點(diǎn)關(guān)注一些業(yè)務(wù)概念被界定的地方、一些與自己邏輯推理有出入的地方。

• 不斷的調(diào)整自己閱讀過(guò)程中記錄的維度，矯正自己的分析方向。

• 老老實(shí)實(shí)用文檔中的原話來(lái)記錄和呈現(xiàn)（這點(diǎn)很重要，特別是閱讀英文材料，最好原汁原味的記錄，有助于提升自己的專業(yè)性）。

2）把書讀薄

這個(gè)時(shí)候的重點(diǎn)是建立“大局觀”，嘗試梳理自己的邏輯主線，常規(guī)邏輯上講都會(huì)劃分為橫縱，或者矩陣式的框架，當(dāng)然這需要建立在前期的理解和分析上，這里常常隱含一個(gè)最最重要的假設(shè)：系統(tǒng)一定是給人用的，一定是解決客戶問(wèn)題的，否則毫無(wú)存在的意義。所以核心的套路是：誰(shuí)？用什么樣的服務(wù)/功能/能力？解決什么樣的問(wèn)題？從而刻畫出：參與者角色、系統(tǒng)能力、交互關(guān)系，需要常常問(wèn)自己的是：邊界是什么？輸入輸出是什么？逐步的通過(guò)用例來(lái)梳理出業(yè)務(wù)功能，形成角色—>主流程—>分支流程，進(jìn)而通過(guò)不斷的歸納演繹形成最終的業(yè)務(wù)抽象描述“一張圖”。

一個(gè)小的細(xì)節(jié)是不能妄圖通過(guò)這些過(guò)程迅速在大腦里完成大圖的繪制，還是需要從小的環(huán)節(jié)做起，把一部分小的業(yè)務(wù)閉環(huán)做成一個(gè)個(gè)的小組塊，不要讓它再占用大腦的空間，然后逐步的整體思考和把握，漸進(jìn)式的形成大圖；與此同時(shí)，大圖的樣式美觀先完全忽略，走通邏輯再細(xì)致調(diào)整。之所以強(qiáng)調(diào)這個(gè)細(xì)節(jié)，是因?yàn)閲L試通過(guò)“一張圖”去描述一個(gè)非常大的業(yè)務(wù)本身就是件很有挑戰(zhàn)的事情，如果不這么做容易讓自己變得焦慮和急躁，這是一個(gè)慢功夫，需要耐心，需要在關(guān)鍵阻塞的地方慢下來(lái)，甚至一遍一遍的反復(fù)才能最終完成。

3）邏輯對(duì)照

這是一個(gè)閉環(huán)封裝的過(guò)程，把前期“讀厚”過(guò)程中的記錄，一些邏輯細(xì)節(jié)、關(guān)鍵流程都要逐一放到大圖里去對(duì)照驗(yàn)證，確保業(yè)務(wù)理解的完整性和準(zhǔn)確性，確保業(yè)務(wù)抽象能夠覆蓋所有已知的業(yè)務(wù)用例，甚至能夠支持可能的業(yè)務(wù)場(chǎng)景。這個(gè)環(huán)節(jié)也是必不可少的部分。

總結(jié)一下業(yè)務(wù)建模（如下圖），通過(guò)上述三個(gè)主要的過(guò)程，我們基本可以產(chǎn)出一些業(yè)務(wù)架構(gòu)的大圖、框圖、流程圖、用例圖等等，是什么樣的圖并不重要，重要的是這個(gè)圖面對(duì)的是誰(shuí)？主要用來(lái)做什么？我后邊也會(huì)講到畫圖角度的問(wèn)題。從我們目前的業(yè)務(wù)場(chǎng)景上看，業(yè)務(wù)架構(gòu)圖的核心目的是統(tǒng)一共識(shí)、減少溝通成本，無(wú)論是項(xiàng)目中的哪個(gè)角色大家都能講一樣的話，描述一樣的事情。這就是建立對(duì)話能力和對(duì)話語(yǔ)境，特別是有大量外部客戶的時(shí)候，一方面體現(xiàn)我們自己專業(yè)性很重要，另外一方面這種與客戶對(duì)話的能力更重要，這也是上文中提到為什么要盡可能用原汁原味的文字去呈現(xiàn)一張圖的目的。

系統(tǒng)建模

通過(guò)業(yè)務(wù)建模完成了從現(xiàn)實(shí)世界到業(yè)務(wù)模型的構(gòu)建，在此基礎(chǔ)上，如何通過(guò)抽象完成業(yè)務(wù)模型到設(shè)計(jì)模型的映射，這是系統(tǒng)建模要解決的問(wèn)題。從研發(fā)實(shí)現(xiàn)的角度，這個(gè)階段會(huì)產(chǎn)出各種各樣的模型圖，比如實(shí)體模型圖、時(shí)序圖、狀態(tài)圖、各個(gè)層次的架構(gòu)圖等等，但是無(wú)論何種角度，何種層次，系統(tǒng)建模一定是在業(yè)務(wù)建模的基礎(chǔ)上，完成業(yè)務(wù)需求到系統(tǒng)模型之間的映射；這其中涉及業(yè)務(wù)功能到系統(tǒng)能力、業(yè)務(wù)流程到數(shù)據(jù)流程的映射；系統(tǒng)建模更強(qiáng)調(diào)職責(zé)、依賴、約束關(guān)系，用于指導(dǎo)研發(fā)的落地實(shí)現(xiàn)。

拋開(kāi)具體的時(shí)序圖、狀態(tài)圖不談，簡(jiǎn)單看一下如下幾個(gè)維度的架構(gòu)圖：

圖片源于網(wǎng)絡(luò)，為示意圖，侵刪

上述幾張圖的視角、層次和面向用戶各不相同，基本上都能看到整體，但是細(xì)節(jié)程度不同，側(cè)重表達(dá)的信息也完全不同。那么系統(tǒng)建模時(shí)應(yīng)該如何去做呢，這個(gè)過(guò)程中我常常用的方法是（不盡然如此）：

• “剝洋蔥式”的由大到小，由粗到細(xì)，覆蓋所有已知和未來(lái)可能業(yè)務(wù)場(chǎng)景；善于利用各種模型表述：自然語(yǔ)言、關(guān)系模型、時(shí)序圖、狀態(tài)圖、流程圖、各種層次架構(gòu)圖等等進(jìn)行模型表述，充分表達(dá)各種業(yè)務(wù)場(chǎng)景并不斷驗(yàn)證。

• 核心實(shí)體抽?。鹤プ『诵母拍睿诵年P(guān)系完成核心模型建立。

• 終極武器：所有的設(shè)計(jì)/邏輯模糊的點(diǎn)，將所有已知場(chǎng)景分別套入，自己講給自己。

1）“剝洋蔥”

在業(yè)務(wù)建模結(jié)果的基礎(chǔ)上進(jìn)行“剝洋蔥”。這是一個(gè)不斷拆解的過(guò)程，這個(gè)過(guò)程中的拆解非常重要的方式是就系統(tǒng)分工。如何分工？哪個(gè)模塊負(fù)責(zé)什么？模塊的輸入和輸出是什么？?jī)?nèi)部提供什么樣的服務(wù)和能力？這幾個(gè)問(wèn)題在后文關(guān)于抽象的部分回答。一句話總結(jié)“剝洋蔥”就是：從業(yè)務(wù)建模的“大局觀”去按職責(zé)分工拆解成多個(gè)子系統(tǒng)、多個(gè)子模塊、然后在模塊能進(jìn)行細(xì)分，層層剝解。

2）核心實(shí)體抽取

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

• 對(duì)象的分析方法

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

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

• 用例分析的方法

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

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

• 問(wèn)題分析的方法

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

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

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

3）終極武器：自己講給自己

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

回到開(kāi)始的那個(gè)問(wèn)題：

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

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

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

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

說(shuō)回抽象

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

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

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

百度百科定義：

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

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

抽象的角度

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

生活中我們常常說(shuō)“我的觀點(diǎn)是…”，其實(shí)這里的“觀點(diǎn)”就是一個(gè)角度問(wèn)題，從一定的立場(chǎng)或角度出發(fā)，對(duì)事物或問(wèn)題所持的看法。以生活中的常見(jiàn)的實(shí)物來(lái)說(shuō)（如下圖），我們是否能快速的說(shuō)出其中的相同點(diǎn)和不同點(diǎn)。

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

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

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

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

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

抽象的層次

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

1. 我的 5 月 18 日的《舊金山紀(jì)事報(bào)》

2. 5 月 18 日的《舊金山紀(jì)事報(bào)》

3. 《舊金山紀(jì)事報(bào)》

4. 一份報(bào)紙

5. 一個(gè)出版品

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

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

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

其實(shí)這個(gè)也不能完全解釋如何分層，原則是什么？我覺(jué)得這是幾個(gè)最通用的原則：

• 公用的往下走
• 個(gè)性的往上走
• 下層可以獨(dú)立于上層存在
• 控制下層的變化

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

抽象的邊界

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

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

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

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

• 
  

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

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

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

抽象的評(píng)估

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

耦合是軟件結(jié)構(gòu)中各模塊之間相互連接的一種度量

內(nèi)聚是一個(gè)模塊內(nèi)部各成分之間相關(guān)聯(lián)程度的度量

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

• 每次從一個(gè)角度來(lái)切分，然后換多個(gè)角度來(lái)審視
• 通過(guò)組合、拆分來(lái)精化、優(yōu)化模型與設(shè)計(jì)（抽象的結(jié)果）
• 關(guān)鍵的審視點(diǎn)：

• 耦合性：減少模塊間通信量
• 內(nèi)聚性：功能單一化
• 變化的隔離性：減少信息依賴，建隔離層、虛擬層

抽象的方法論（套路）

我想，至此，我們說(shuō)清楚了前面的那兩個(gè)問(wèn)題：

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

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

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

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

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

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

• 但不絕對(duì)，自上而下和自下而上，往往在過(guò)程中是隨意切換的

下面這張圖來(lái)自于《Thinking in UML》，我覺(jué)得這個(gè)循環(huán)的過(guò)程可以表達(dá)上面這四個(gè)點(diǎn)，供大家參考。

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

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

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

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

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

• 解決溝通障礙：達(dá)成共識(shí)、減少歧義。

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

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

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

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

怎么畫？

先說(shuō)分類

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

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

• 
  

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

這其中：

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

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

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

再說(shuō)構(gòu)圖

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

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

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

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

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

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

如何評(píng)判架構(gòu)圖的好壞

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

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

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

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

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

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

但是，終歸還是那句話，“一張圖片勝過(guò)千言萬(wàn)語(yǔ)”。不管好壞，不管是否美觀，人是視覺(jué)動(dòng)物，用圖表達(dá)可以極大的提升溝通效率，先畫起來(lái)吧！

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

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

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

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

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

不要屁股決定腦袋

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

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

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

最后的最后

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

參考文檔

為什么我們需要架構(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)》

網(wǎng)站標(biāo)題：如何畫好一張架構(gòu)圖？
文章URL：http://muchs.cn/news3/103753.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供做網(wǎng)站、品牌網(wǎng)站建設(shè)、網(wǎng)站營(yíng)銷、自適應(yīng)網(wǎng)站、網(wǎng)站排名、關(guān)鍵詞優(yōu)化

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)