如何畫好一張架構圖？（內含知識圖譜）

時間 2020-06-17

原文原文鏈接

做者 | 簫逸阿里文娛高級技術專家html

關注「阿里巴巴雲原生」公衆號，回覆架構便可查看清晰知識大圖！程序員

導讀：架構圖是什麼？爲何要畫架構圖？如何畫好架構圖？有哪些方法？本文從架構的定義提及，分享了阿里文娛高級技術專家簫逸關於畫架構圖多年的經驗總結，並對抽象這一律念進行了深刻地討論。內容較長，同窗們可收藏起來細細閱讀。編程

什麼是架構圖？

如何畫好一張架構圖，要作好這件事情首先要回答的就是什麼是架構圖。咱們平常工做中常常能看到各類各樣的架構圖，並且常常會發現你們對架構圖的理解各有側重。深刻追究到這個問題，可能一會兒還很難有一個具象的定義，若是咱們把這個問題進行拆分，理解起來就會容易一點。安全

架構圖 = 架構 + 圖

按照這個等式，咱們能夠把問題轉換：網絡

架構是什麼？
圖是什麼？

圖是什麼？這個比較容易回答，圖是一種信息的表達方式，因此架構圖，即表達「架構」的圖，也就是一種架構的表達方式。也即：架構圖=架構的表達=表達架構的圖。架構

按照這種思路咱們須要回答：框架

什麼是架構？要表達的究竟是什麼？
如何畫好一張架構圖？

接下來的內容基本上就是按照這兩個維度來作分析。less

什麼是架構？要表達的究竟是什麼？

Linus 03 年在聊到拆分和集成時有一個很好的描述：異步

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.（讓咱們認識到一種現象，把 複雜系統拆分紅模塊，彷佛並無下降 整個系統的複雜度。它下降的只是 子系統的複雜度。而整個系統的複雜度，反而會因爲拆分後的模塊之間，不得不進行交互，變得更加複雜。）

我理解這裏描述的系統拆分就是架構的過程，基本出發點是爲了效率，經過架構的合理拆分（不管是空間仍是時間上的拆分），最終目的讓效率最大化。那到底什麼是架構，其實沒有徹底統一且明確的定義，以下三個定義能夠參考。微服務

在百度百科上的定義：

架構，又名軟件架構，是有關軟件 總體結構與組件的 抽象描述，⽤於指導⼤型軟件系統各個方面的設計。

在 Wikipedia 上的定義：

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

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. 架構的本質

這裏引用三個觀點來探討架構的本質：

架構的本質是爲了管理複雜性；
架構的本質就是對系統進行有序化重構，不斷減小系統的「熵」，使系統不斷進化；
架構的本質就是對系統進行有序化重構，以符合當前業務的發展，並能夠快速擴展。

上述三個觀點提到的內容，基本表達了架構的核心目的：管理複雜性，效率最大化。以及架構的兩個主要變化來源：一個是以改善軟件質量爲目的的內在結構性變化；另一個是以知足客戶需求爲目的的外在功能性變化。

不管是何種變化，在我看來架構都是在不斷的判斷和取捨，在業務需求和系統實現之間作權衡，從而來應對將來變化的不肯定性，以下圖能夠比較粗淺直觀的表達這種理解。

2. 要表達的是什麼？

在 EA 架構領域，有兩種常見架構方法 RUP 和 TOGAF，這兩個框架也是咱們經常瞭解架構分類的兩個維度。從我的的角度，我本身以爲 TOGAF 的分類方式更加普遍使用（以下右圖）。

結合平常的業務開發，其實咱們更多的是關注業務架構和應用架構，因此把上邊的表達式進一步的拆解，在回答如何畫好一張架構圖以前，咱們須要關注業務架構和系統架構，討論清楚如何進行業務架構和系統架構。

3. 架構的過程其實就是建模的過程

咱們都知道現實世界到軟件世界或者面向對象的世界的過程，是一個不斷抽象的過程，這其中的方法就是不斷的創建模型。從現實世界到業務模型，從業務模型到概念模型，從概念模型到設計模型，經過不斷的抽象去粗取精，造成對現實世界的層層抽象，因此架構的過程其實就是建模的過程。至此，咱們有必要了解一下什麼是建模。

百度百科定義：

建模就是 創建模型，就是爲了理解事物而對事物作出的一種抽象，是對事物的一種無歧義的書面描述。

《Thinking in UML》定義：

建模（Modeling），是指經過對客觀事物 創建一種抽象的方法用以表徵事物並得到對事物自己的理解，同時把這種 理解概念化，將這些 邏輯概念組織起來，構成一種對所觀察的對象的內部結構和工做原理的便於理解的表達。

從上述兩個定義上基本能夠了解到建模就是抽象，對業務或現實世界的抽象，雖然不足以幫咱們理解架構自己，可是能夠將咱們上述關注的業務架構和系統架構進一步向下 Down 一層，架構的過程是建模的過程，咱們轉換成兩個簡單的問題：模是什麼？如何建？

4. 模是什麼？如何建？

這是兩個比較容易陷入理論性的問題，咱們跳出來從結果看過程。接下來經過已經產出的一些架構圖來反向看這些架構圖是如何產出的，同時來回答這兩個問題。

1）業務建模

回到當下業務自己，對我而言也是全新的，在最初接觸的時候憑僅有的行業背景去理解，結合了大量的文檔閱讀最終產出了以下圖示的《業務核心流程圖》和《業務功能模塊圖》。這兩張圖基本上就涵蓋了全部的業務內容。左邊的業務流程圖獲得了這個行業 20 多年從業經驗專家承認，他認爲這就是 20 多年所從事的業務內容。

圖片源於網絡，爲示意圖，侵刪

回溯整個過程，特別是左側的業務核心流程圖，今天咱們看這張流程圖很容易構架起一個基本邏輯來，縱向是不一樣的業務角色和系統，橫向是時間的推動，特別容易理解。但我想說最開始的理解和分析是極其耗時和壓力極大的過程。這個過程當中我所用的方法就是：

「把書讀厚」：大量的信息輸入，同時探求可能性；
「把書讀薄」：歸類彙總，造成大圖；
邏輯對照，確保理解和分析的正確性。

把書讀厚：

下圖基本涵蓋「把書讀厚」的過程，匯聚大量的文檔信息，嘗試用多維度去造成邏輯。這個維度多是依據歷史經驗，也多是依據文檔內容，好比在造成業務大圖的過程當中，我曾按可能的場景邏輯、可能的系統或領域邏輯分別把多個文檔中的內容歸類，探求可能性。

這個過程會很枯燥，特別是涉及一些業務的術語內容，理解起來就會很困難。個人方式就是把本身當作一名「探索者」，如同咱們玩遊戲同樣，經常問本身「個人遊戲地圖所有點亮了嗎？」未必要照顧到全部細節，可是須要力求覆蓋總體內容。仔細想一想，彷佛也和平常的讀書相似，這期間值得注意的是：

重點關注一些業務概念被界定的地方、一些與本身邏輯推理有出入的地方；
不斷的調整本身閱讀過程當中記錄的維度，矯正本身的分析方向；
老老實實用文檔中的原話來記錄和呈現（這點很重要，特別是閱讀英文材料，最好原汁原味的記錄，有助於提高本身的專業性）。

把書讀薄：

這個時候的重點是創建「大局觀」，嘗試梳理本身的邏輯主線，常規邏輯上講都會劃分爲橫縱，或者矩陣式的框架，固然這須要創建在前期的理解和分析上，這裏經常隱含一個最最重要的假設：系統必定是給人用的，必定是解決客戶問題的，不然毫無存在的意義。因此核心的套路是：誰？用什麼樣的服務/功能/能力？解決什麼樣的問題？從而刻畫出：參與者角色、系統能力、交互關係，須要經常問本身的是：邊界是什麼？輸入輸出是什麼？逐步的經過用例來梳理出業務功能，造成角色—>主流程—>分支流程，進而經過不斷的概括演繹造成最終的業務抽象描述「一張圖」。

一個小的細節是不能妄圖經過這些過程迅速在大腦裏完成大圖的繪製，仍是須要從小的環節作起，把一部分小的業務閉環作成一個個的小組塊，不要讓它再佔用大腦的空間，而後逐步的總體思考和把握，漸進式的造成大圖；與此同時，大圖的樣式美觀先徹底忽略，走通邏輯再細緻調整。之因此強調這個細節，是由於嘗試經過「一張圖」去描述一個很是大的業務自己就是件頗有挑戰的事情，若是不這麼作容易讓本身變得焦慮和急躁，這是一個慢功夫，須要耐心，須要在關鍵阻塞的地方慢下來，甚至一遍一遍的反覆才能最終完成。

邏輯對照：

這是一個閉環封裝的過程，把前期「讀厚」過程當中的記錄，一些邏輯細節、關鍵流程都要逐一放到大圖裏去對照驗證，確保業務理解的完整性和準確性，確保業務抽象可以覆蓋全部已知的業務用例，甚至可以支持可能的業務場景。這個環節也是必不可少的部分。

總結一下業務建模（以下圖），經過上述三個主要的過程，咱們基本能夠產出一些業務架構的大圖、框圖、流程圖、用例圖等等，是什麼樣的圖並不重要，重要的是這個圖面對的是誰？主要用來作什麼？我後邊也會講到畫圖角度的問題。從咱們目前的業務場景上看，業務架構圖的核心目的是統一共識、減小溝通成本，不管是項目中的哪一個角色你們都能講同樣的話，描述同樣的事情。這就是創建對話能力和對話語境，特別是有大量外部客戶的時候，一方面體現咱們本身專業性很重要，另一方面這種與客戶對話的能力更重要，這也是上文中提到爲何要儘量用原汁原味的文字去呈現一張圖的目的。

2）系統建模

經過業務建模完成了從現實世界到業務模型的構建，在此基礎上，如何經過抽象完成業務模型到設計模型的映射，這是系統建模要解決的問題。從研發實現的角度，這個階段會產出各類各樣的模型圖，好比實體模型圖、時序圖、狀態圖、各個層次的架構圖等等，可是不管何種角度，何種層次，系統建模必定是在業務建模的基礎上，完成業務需求到系統模型之間的映射；這其中涉及業務功能到系統能力、業務流程到數據流程的映射；系統建模更強調職責、依賴、約束關係，用於指導研發的落地實現。

拋開具體的時序圖、狀態圖不談，簡單看一下以下幾個維度的架構圖：

圖片源於網絡，爲示意圖，侵刪

上述幾張圖的視角、層次和麪向用戶各不相同，基本上都能看到總體，可是細節程度不一樣，側重表達的信息也徹底不一樣。那麼系統建模時應該如何去作呢，這個過程當中我經常用的方法是（不盡然如此）：

「剝洋蔥式」的由大到小，由粗到細，覆蓋全部已知和將來可能業務場景；善於利用各類模型表述：天然語言、關係模型、時序圖、狀態圖、流程圖、各類層次架構圖等等進行模型表述，充分表達各類業務場景並不斷驗證；
核心實體抽取：抓住核心概念，核心關係完成核心模型創建；
終極武器：全部的設計/邏輯模糊的點，將全部已知場景分別套入，本身講給本身。

「剝洋蔥」：

在業務建模結果的基礎上進行「剝洋蔥」。這是一個不斷拆解的過程，這個過程當中的拆解很是重要的方式是就係統分工。如何分工？哪一個模塊負責什麼？模塊的輸入和輸出是什麼？內部提供什麼樣的服務和能力？這幾個問題在後文關於抽象的部分回答。一句話總結「剝洋蔥」就是：從業務建模的「大局觀」去按職責分工拆解成多個子系統、多個子模塊、而後在模塊能進行細分，層層剝解。

核心實體抽取：

關於核心實體的抽取，這裏的關鍵問題是：哪些是實體？如何判斷核心實體？如何抽取？抽取後的結果是什麼樣的？很難用一種方法論的形式去描述，我也沒有徹底造成我本身一成不變的方法論，可是我以爲以下三種方式能夠供你們參考。

對象的分析方法

實體（Entity）：客觀存在並可相互區別的事物稱之爲實體。實體能夠是具體的人、事、物,也能夠是抽象的概念或聯繫。

從這個概念理解，和咱們面向對象萬物兼對象的理解是基本一致的。因此實體的抽取也能夠借鑑對象分析的方法：獨立、可抽象、有層次性、在單個層次上又具有原子性。以下圖是《Thinking in UML》中關於對象的分析方法。

用例分析的方法

經過從業務用例中，去提取其中的關鍵詞，不一樣的關鍵詞可能表達了實體、關係、屬性等等內容，從而完成模型分析與創建。這裏引用六銖老師在《問題空間領域模型基本抽象方法》中的的內容，簡述以下：

一句完整的用例描述中，首先找名詞，以「主語」和「賓語」爲主，這些名詞基本能夠肯定咱們的實體；其次找形容詞，存在於「定語」和「狀語」中，找到形容詞基本能夠肯定對應屬性的值；而後經過對用例的補充，細化，對名詞進行定義，慢慢的，咱們會獲得咱們的領域模型和對應的屬性。最後經過動詞&形容詞（存在於【謂語】，【狀語】，【定語】）來肯定他們之間的關聯關係。

問題分析的方法

這是《聊聊架構》中提的方式，具體講就是經過尋找問題的主體，而後分析主體的生命週期，進而經過區分生命週期裏的關鍵活動來聚焦主體的關鍵屬性和關鍵關係。推薦你們閱讀前 9 章的內容，總計才 40 頁的內容，可能會有所體會。這裏舉一個書中的例子：

一個笑話：一位女士對老公說：把袋子裏的土豆削一半下鍋；結果全部土豆都下鍋了，並且每一個土豆被削了一半。

做者指出，這裏其實就沒有清晰的設別主體，這個主體不單是土豆，而是隱含的人要吃土豆，包括人和土豆兩個實體，這兩個實體之間的關係就是要解決的業務場景：怎樣吃？如何吃？爲何吃？因此主體識別不清楚，可能會致使總體實現的偏離。固然實際過程當中不會犯這麼愚蠢的錯誤，可是也側面說明核心實體的抽取是很是關鍵的。

終極武器 - 本身講給本身：

實際的業務開發中，每每一種業務設計實現要知足上層N個業務場景，這其中有共性也有個性化訴求，這個過程當中咱們很容易被多場景之間的異同搞混亂，要麼邏輯不清晰、要麼過分設計、要麼考慮不周。我觀察過不少同窗包括我本身，在必定的業務複雜度時容易失去設計的焦點。個人作法與業務建模相似，必定要邏輯對照：在全部的設計/邏輯模糊的點，將全部已知場景分別套入，本身講給本身。請注意這裏是「分別套入」，在當前的設計層次下一個場景驗證完再去驗證下一個場景，找出阻塞的、模糊的點，從新梳理再優化設計。系統建模的結果指導咱們軟件設計實現，因此必定要反覆梳理打通，這個反覆的過程其實也是提高架構能力的過程，累積到必定程度就會天然通透。

回到開始的那個問題：

模是什麼？經過上面業務建模和系統建模的描述，簡單來說模就是業務的映射，這個映射的結果是業務模型、概念模型或設計模型，可是全部的出發點都是業務需求：客戶是誰？核心訴求是什麼？

如何建？上面經過業務建模和系統建模兩個維度，從我的實踐角度大概講了常規的套路，建模的本質其實一個抽象的過程，可是上述業務和系統建模抽象的過程其實還有兩個問題並無徹底說清楚：

業務建模中「把書讀薄」歸類彙總，創建「大局觀」，造成大圖，這裏按什麼維度去歸類？如何判斷歸類是正確的？
系統建模中「剝洋蔥」怎麼拆？按什麼拆？上述架構圖中的層次、領域如何劃分層次？邊界在哪裏？

說回抽象

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

"abstraction, abstraction, abstraction"are the three most important things in programming.

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

百度百科定義：

從具體事物抽出、歸納出它們共同的方面、本質屬性與關係等，而將個別的、非本質的方面、屬性與關係捨棄，這種思惟過程，稱爲抽象。

若是更精煉的歸納：抽象就是作減法和作除法。經過捨棄非本質和可有可無的部分，着眼於問題的本質，去粗取精；經過透過現象看本質，發現不一樣事物之間的共同之處，異中求同，同類歸併，也就是作除法。上文中建模過程是共性抽象，經過不斷的抽象達到某個狀態爲止，我理解這個狀態沒有肯定性的答案，核心就是知足業務場景的須要，其實這背後也有一個邊界的問題。

1. 抽象的角度

生活中到處都是抽象，可是咱們彷佛少了爲何是這樣或那樣抽象的思考。抽象是有角度之分的。

生活中咱們經常說「個人觀點是…」，其實這裏的「觀點」就是一個角度問題，從必定的立場或角度出發，對事物或問題所持的見解。以生活中的常見的實物來講（以下圖），咱們是否能快速的說出其中的相同點和不一樣點。

如圖中已經標註的，咱們從功用的角度對它們定義了椅子、桌子、凳子和櫃子這樣的區分，但顯然頗有不少不少角度，好比：物料、文字、高矮等等維度，從不一樣維度看過去，會有徹底不一樣的相同點和不一樣點表述，因此，本質是什麼？本質是：

抽象角度其實也是分類的角度，角度不一樣，會致使徹底不一樣建模方向和結果；
抽象的角度就是建模的方向和目的（「屁股決定腦殼」）。

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

同時，上文中咱們提到，模是業務的映射，基於對抽象的理解，咱們能夠進一步展開：模是在肯定抽象角度下的業務映射。

2. 抽象的層次

Wikipedia 關於抽象的定義中有一個關於報紙的例子：

個人 5 月 18 日的《舊金山紀事報》

5 月 18 日的《舊金山紀事報》

《舊金山紀事報》

一份報紙

一個出版品

這五句話中，咱們能夠感覺到抽象的層次，抽象層次越高，細節越少，普適性越強。再好比下圖中關於網絡模型的抽象，關於操做系統內核的抽象，咱們能夠明顯的看到不一樣層次的抽象，就是過濾不一樣的信息，最終留下來的信息纔是當前抽象層次所須要的信息。從系統設計實現上來講，抽象層次越高，越接近設計，越遠離實現，同時抽象的模型越不受細節的羈絆，穩定性越高，普適性越強，可重用性就越高。

那麼這裏抽象的劃分層次的依據是什麼？原則又是什麼？個人經驗是，劃分抽象層次的依據主要包含兩個：

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

其實這個也不能徹底解釋如何分層，原則是什麼？我以爲這是幾個最通用的原則：

公用的往下走
個性的往上走
下層能夠獨立於上層存在
控制下層的變化

考慮抽象層次的好處是不論在哪個層次上，咱們只須要面對有限的複雜度，從而專心考慮這個層次上的抽象是什麼，要表達的信息是什麼。

3. 抽象的邊界

除了角度、層次以外，咱們還須要考慮的抽象的邊界。若是說層次考慮的是縱向維度的表達，那麼邊界考慮的是橫向維度的表達。如何肯定邊界，一個總的原則是按照職責進行劃分，這裏的職責其實也就是分工。一旦職責肯定，咱們在作建模分析時就不須要把整個業務大局放進來從頭至尾去分析一遍，咱們只須要考慮當前分工下的上游和下游便可，這樣的信息量大大減小，天然的咱們面對的領域複雜度也會下降到必定程度。

若是必定要給出邊界的定義，個人理解是：邊界是在肯定抽象角度下，經過尋找核心的業務活動，抽取核心實體，進一步肯定實體核心生命週期的結果。可能有一點點繞，關鍵詞是：核心業務活動、核心實體、核心實體生命週期。

以現場娛樂行業爲例，以下這張圖包含了最高抽象層次下業務的全生命週期，這個抽象層次下的主體是什麼，個人理解是票，項目生產的結果是票，分銷或電商服務是對票的銷售，現場是對票的核驗，至此以票爲核心實體的生命週期結束。

若是咱們往下 Down 一層，從項目生產這一個業務活動去看，整個業務流程是這樣：

項目管理->場館座位分銷->票房預測->場次管理->配額管理->繪座->票房規劃

從生產這個視角去看，核心的實體不是票，而是場次（肯定時間、肯定地點、肯定內容的一場演出或賽事），全部的關鍵業務活動都是以場次爲維度，生產領域裏須要考慮的主要就是場次的核心生命週期。

因此，在不一樣的抽象角度、不一樣的抽象層次，根據分工的不一樣會有不一樣的核心業務活動、不一樣的核心實體、邊界的肯定關鍵在尋找核心的生命週期。尋找生命週期的過程，就是發現內聚的過程；將全部關於生命週期的業務活動累積，就能夠提高領域或模塊的內聚性。

4. 抽象的評估

前邊咱們基本說清楚了抽象的角度、層次和邊界，從三個維度肯定了抽象的結果。那麼如何評估抽象結果的好壞呢？答案是「高內聚，低耦合」，固然還有更多的原則，可是單從實踐的角度，我以爲這是最最重要的。

· 耦合是軟件結構中各模塊之間相互鏈接的一種度量；
· 內聚是一個模塊內部各成分之間相關聯程度的度量。

「高內聚，低耦合」從內部、外部兩個視角去評估抽象結果的好壞。這其中也有對應的原則和方法論，常規的套路是：

每次從一個角度來切分，而後換多個角度來審視
經過組合、拆分來精化、優化模型與設計（抽象的結果）
關鍵的審視點：耦合性：減小模塊間通訊量；內聚性：功能單一化；變化的隔離性：減小信息依賴，建隔離層、虛擬層。

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

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

業務建模中「把書讀薄」歸類彙總，創建「大局觀」，造成大圖，這裏按什麼維度去歸類？如何判斷歸類是正確的？
系統建模中「剝洋蔥」怎麼拆？按什麼拆？上述架構圖中的層次、領域如何劃分層次？邊界在哪裏？

總結前面說的全部關於抽象的內容，造成抽象的方法論（套路）：

抽象有兩種方法，一種是自頂向下，另外一種是自底向上；
業務建模，是從小到大，從局部到總體，自底向上的概括、演繹的抽象過程；
系統建模，是從大到小，從總體到局部，自頂向下的拆解、切分的抽象過程；
但不絕對，自上而下和自下而上，每每在過程當中是隨意切換的。

下面這張圖來自於《Thinking in UML》，我以爲這個循環的過程能夠表達上面這四個點，供你們參考。

如何畫好一張架構圖？

回到主題，若是上邊的問題說清楚了，接下來的事情就相對簡單了。對於架構圖是什麼這個問題，咱們能夠把以前的等式進行延展：架構圖 = 架構的表達 = 架構在不一樣抽象角度和不一樣抽象層次的表達，這是一個天然而然的過程。不是先有圖再有業務流程、系統設計和領域模型等，而是相反，用圖來表達抽象的思考和內容。

那麼架構圖有什麼用？給誰看？回答這個問題須要講清楚爲何要畫架構圖，同時也須要考慮一個問題就是：架構圖是否是越多越好，越詳細越好？

1. 畫架構圖是爲了什麼？

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

解決溝通障礙：達成共識、減小歧義；
提高協做效率：團隊內部和團隊之間的協做、溝通、願景和指導。

可是上述兩點實際上是很是籠統的信息，若是放在 What 層面，咱們必需要考慮架構圖面對的「客戶」，不一樣的客戶有不一樣的訴求（其實也就是角度和層次），在不一樣的抽象層次架構圖所表達的信息內容能夠徹底不同。以目前團隊作的事情爲例，架構圖的目標客戶至少有幾類：

參與項目的各團隊各角色（業務、產品、開發、測試、安全、GOC）
項目以外的客戶（外部客戶，外部評審專家）
各層次 TL（彙報，跨 BU，跨團隊協做溝通）

因此畫架構圖，咱們必須首先明確溝通交流的目的和麪向的客戶，只有明確了這兩個點才能更加有針對性的達成上邊所說的那兩點目標：解決溝通障礙，提高協做效率。

2. 怎麼畫？

1）先說分類

架構圖分類，本質上是從不一樣的視角，不一樣的抽象角度去看，做出清晰、簡化的描述，涵蓋特色方面忽略無關方面。

從業務應用開發的維度，通常的抽象層次能夠分爲：

業務全域—>子域—>模塊—>子模塊—>包—>類—>方法

這其中：

較低層次的抽象：應用內部包圖、類圖；某個領域：實體圖、時序圖、狀態圖、用例圖等等；
較高層次的抽象：具備必定的複雜性，好比微服務架構，系統間的交互圖，領域/子領域架構圖，整個系統架構圖等等。

固然，還有不少其餘的分類方式，好比：RUP 4+1，GOGAF9 等等分類方式。單從實踐的角度，我以爲何種分類不是最重要的，最重要的是想清楚面向誰和解決什麼訴求，而後思考架構圖到底從哪一個角度、哪一個層次去抽象。咱們目前所作的項目，有很時候要去和國外的業務專家、技術專家去溝通，你們也並無一個明確的標準定義，表述清楚問題，達成共識這是最最關鍵的，至於架構圖的粒度、類別、內容能夠逐步的去完善，去粗取精，迭代優化。

2）再說構圖

構圖的部分，咱們你們都用 UML 畫過類圖，涉及泛化、聚合、組合、依賴等等關係，分別用不一樣的虛實線、箭頭樣式進行表達。因此畫架構圖須要考慮架構圖的組成元素，要保證符合一向理解，架構圖的組成元素可能涉及：

方框、各類形狀、虛實線、箭頭、顏色（不一樣顏色表明什麼意思）和文字內容；
虛實線表達什麼？組件類型，模塊類型，層，服務，須要考慮是否已經實現等？不一樣狀態的標識怎麼傳遞？
箭頭表達什麼?數據流或關聯關係？
交互類型能夠是同步或異步的；關聯類型能夠是指依賴、繼承、實現。

構圖最最重要的是須要考慮內容術語一致性問題、碎片化問題、信息粒度大小的問題，以及圖表的外觀問題。

3. 如何評判架構圖的好壞

架構圖的好壞，我理解主要是兩個方向，一個是須要跳出圖自己去看，業務領域的抽象設計合理性，是否符合「高內聚，低耦合」的要求，這個須要回到前文的業務建模、系統建模和抽象過程去尋找答案。另一個方向是圖自己，如下幾個點供參考：

內容術語一致、信息粒度大小一致，圖例清晰，顏色類型統一，美觀；
圖中的信息與相應的抽象級別相關，且知足利益相關者(合做方)的需求；
一張好的架構圖不須要多餘的文字解釋！受衆有沒有準確接收到想傳遞的信息；若是它所致使的疑問比它能解釋的問題還要多，那麼它就不是一張好的架構圖；
架構圖應該幫助每一個人看到大局，瞭解周圍的環境，適當的上下文信息；
架構圖應該避免「只見樹木，不見森林」。

可是，終歸仍是那句話，「一張圖片賽過千言萬語」。無論好壞，無論是否美觀，人是視覺動物，用圖表達能夠極大的提高溝通效率，先畫起來吧！

最後也聊聊架構師

這是來自於阿白老師的文章《架構師究竟是作什麼的？》，越是琢磨，越以爲深覺得然。其中提到了好的架構師的畫像和很差的畫像，以下圖，與你們共勉。

從我我的的成長經歷看，架構師很重要的一點要學會「權衡」，既要兼顧當下痛點也要符合將來必定時間的發展，既要保留將來的可擴展性也要避免過分設計。選擇什麼樣的時間節點、什麼樣的業務場景以及什麼樣的架構迭代策略相當重要，這些決策的關鍵在於判斷和取捨，須要結合深入的業務思考乃至組織架構去作權衡落地。一點點不算經驗的經驗：

1. 快速學習

快不是一個速度問題，也是一個判斷或者標準問題。面對一個全新業務場景，如何可以識別20%的關鍵業務路徑，關鍵業務痛點，如何短期把本身變成業務專家這是一個架構師基本的素質。個人一點經驗就是要去「吸金式」的思考，帶着問題主動思考，客戶是誰？有什麼訴求？須要解決什麼樣的問題？咱們能提供什麼樣的價值？多問爲何？這也須要長時間的刻意訓練。

2. 不要屁股決定腦殼

要跨角色、跨層級去看待業務問題，這個點容易陷入說教，說實話我本身作得也未必到位。可是時刻提醒本身的思考是否被侷限，在哪個維度，是 Have-do-be，仍是 be-do-Have 等等；同時也不斷的在提醒本身永遠不要屁股決定腦殼。

3. 提高思考能力和對於技術原理或本質的理解

我以爲這是最底層的能力，業務開發中我以爲最大的兩個難點：一是邏輯的複雜性，二是需求的變化性。咱們不該該大部分時間花在尋找解決方案上，而應該花更多的時間在選擇解決方案上。這就要求咱們對業務全局、行業深度、技術視野、技術深度、業務共性、個性特徵等等造成本身的認知。權衡取捨，取什麼舍什麼？該怎麼取怎麼舍？那個度在哪裏？惟有思考，自驅，累積和堅持，勇猛精進，志願無倦。