作者 | 箫逸 阿裡文娛進階技術專家
關注“阿裡巴巴雲原生”公衆号，回複 架構 即可檢視清晰知識大圖！
導讀：架構圖是什麼？為什麼要畫架構圖？如何畫好架構圖？有哪些方法？本文從架構的定義說起，分享了阿裡文娛進階技術專家箫逸關于畫架構圖多年的經驗總結，并對抽象這一概念進行了深入地讨論。内容較長，同學們可收藏起來細細閱讀。
什麼是架構圖？
如何畫好一張架構圖，要做好這件事情首先要回答的就是什麼是架構圖。我們日常工作中經常能看到各種各樣的架構圖，而且經常會發現大家對架構圖的了解各有側重。深入追究到這個問題，可能一下子還很難有一個具象的定義，如果我們把這個問題進行拆分，了解起來就會容易一點。
架構圖 = 架構 + 圖 按照這個等式，我們可以把問題轉換：
- 架構是什麼？
- 圖是什麼？
圖是什麼？這個比較容易回答，圖是一種資訊的表達方式，是以架構圖，即表達“架構”的圖，也就是一種架構的表達方式。也即：架構圖=架構的表達=表達架構的圖。
按照這種思路我們需要回答：
- 什麼是架構？要表達的到底是什麼？
- 如何畫好一張架構圖？
接下來的内容基本上就是按照這兩個次元來做分析。
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. 提升思考能力和對于技術原理或本質的了解
我覺得這是最底層的能力，業務開發中我覺得最大的兩個難點：一是邏輯的複雜性，二是需求的變化性。我們不應該大部分時間花在尋找解決方案上，而應該花更多的時間在選擇解決方案上。這就要求我們對業務全局、行業深度、技術視野、技術深度、業務共性、個性特征等等形成自己的認知。權衡取舍，取什麼舍什麼？該怎麼取怎麼舍？那個度在哪裡？唯有思考，自驅，累積和堅持，勇猛精進，志願無倦。
最後的最後
希望這篇文章對大家有幫助，附上最初在考慮這個主題時的構思過程及思考路徑，供大家參考。
參考文檔：
- 為什麼我們需要架構圖( https://new.qq.com/omn/20190131/20190131A16MWK.html)
- 軟體架構圖的藝術 ( https://www.infoq.cn/article/crafting-architectural-diagrams)
- 邏輯架構和實體架構 ( https://www.cnblogs.com/dinglang/p/4565378.html)
- 一篇文章讀懂分層架構 ( https://zhuanlan.zhihu.com/p/40353581)
- TOGAF & RUP( https://www.ibm.com/developerworks/cn/rational/rationaledge/content/feb07/temnenco/index.html)
- 如何自底向上推導應用邏輯架構？+如何自頂向下建構架構？（節選）( https://developer.aliyun.com/article/727436)
- 《大象：Thinking in UML》
- 《聊聊架構》
關注“阿裡巴巴雲原生”公衆号，回複“架構”即可檢視清晰知識大圖！
課程推薦
為了更多開發者能夠享受到 Serverless 帶來的紅利，這一次，我們集結了 10+ 位阿裡巴巴 Serverless 領域技術專家，打造出最适合開發者入門的 Serverless 公開課，讓你即學即用，輕松擁抱雲計算的新範式——Serverless。
點選即可免費觀看課程：
https://developer.aliyun.com/learning/roadmap/serverless“ 阿裡巴巴雲原生 關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的公衆号。”