畫架構圖分四步走：
第一，搞清楚要畫的架構圖的類型；
第二，確認架構圖中的關鍵要素（比如產品、技術、服務）；
第三，梳理關鍵要素之間的關聯：包含、支撐、同級並列等；
第四，輸出關聯關係清晰的架構圖。
應用架構圖
接下來，我們作進一步解讀：
一、架構圖的定義及作用
什麼是架構圖？維基百科、百度百科其實都沒有關於它的直接定義。不過我們可以進行拆分理解：
- 架構圖=架構+圖
這樣問題就轉化成，什麼是架構，以及什麼是圖？
關於架構，百度百科上是這樣定義的：
架構，又名軟件架構，是有關軟件整體結構與組件的抽象描述，於指導型軟件系統各個方面的設計。
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.（系統架構，體現在它的組成部分、它們之間的相互關係和環境中，以及控制其設計和演化的原則。）
也就是說，架構是由系統組件，以及組件間相互關係共同構成的集合體。
而架構圖，則是用來表達這種集合的載體。
它的作用也很簡單，兩個：
- 劃分目標系統邊界
- 將目標系統的結構可視化
進而減少溝通障礙，提升協作效率。
二、架構的分類及畫法
架構大致可以分爲4類：業務架構、應用架構、數據架構和技術架構，整體邏輯關係如下：
架構分類
業務架構：使用一套方法論/邏輯對產品（項目）所涉及到的業務進行邊界劃分。所以熟悉業務是關鍵。
比如做一個團購網站，你需要把商品類目、商品、訂單、訂單服務、支付、退款等進行清晰劃分，而業務架構不需要考慮諸如我用什麼技術開發、我的併發大怎麼辦、我選擇什麼樣的硬件等等。
產品架構圖
應用架構：它是對整個系統實現的總體上的架構，需要指出系統的層次、系統開發的原則、系統各個層次的應用服務。
例如，下圖就將系統分爲數據層、服務層、通訊層、展現層，並細分寫明每個層次的應用服務。
應用架構圖
數據架構：是一套對存儲數據的架構邏輯，它會根據各個系統應用場景、不同時間段的應用場景 ，對數據進行諸如數據異構、讀寫分離、緩存使用、分佈式數據策略等劃分。
數據架構主要解決三個問題：第一，系統需要什麼樣的數據；第二，如何存儲這些數據；第三，如何進行數據架構設計。
大數據架構圖
技術架構：應用架構本身只關心需要哪些應用系統，哪些平臺來滿足業務目標的需求，而不會關心在整個構建過程中你需要使用哪些技術。技術架構則是應接應用架構的技術需求，並根據識別的技術需求，進行技術選型，把各個關鍵技術和技術之間的關係描述清楚。
技術架構解決的問題包括：純技術層面的分層、開發框架的選擇、開發語言的選擇、涉及非功能性需求的技術選擇。
補充介紹軟件架構中最經典的“4+1視圖”：
所謂“4+1視圖”，分別爲場景視圖、邏輯視圖、物理視圖、處理流程視圖和開發視圖。
01 邏輯視圖
用於描述系統的功能需求，即系統給用戶提供哪些服務；以及描述系統軟件功能拆解後的組件關係、組件約束和邊界，反映系統整體組成與系統如何構建的過程。在UML中由類圖來表示（關於什麼是類圖，這裏有一篇通俗易懂的介紹），
下面springcloud微服務的邏輯視圖示例（僅部分），就描述了springcloud中各個功能組件。從這個圖中，基本可以對springcloud有一個大顆粒度的瞭解。
springcloud微服務的邏輯視圖
02 物理視圖
開發出的軟件系統，最終是要運行在物理或軟件環境上。物理環境可能是服務器、PC機、移動終端等物理設備；軟件環境可以是虛擬機、容器、進程或線程。部署視圖就是對這個部署信息進行描述。在UML中通常由部署圖表示。
03 處理視圖
處理視圖，又稱過程視圖、運行視圖。用於描述系統軟件組件之間的通信時序，數據的輸入輸出。在UML中通常由時序圖和流程圖表示，如下圖所示：
微服務架構安全認證處理視圖
04 開發視圖
開發視圖關注軟件開發環境下實際模塊的組織，反映系統開發實施過程。
一個設計良好的開發視圖，應該能夠滿足以下要求：
通過邏輯架構元素，能夠找到它所有代碼和所有的二進制交付件 每一個代碼源文件，都能夠找到它所屬的邏輯架構元素 每一個二進制交付件，都能夠找到它集成了哪些邏輯架構元素
設備調試系統架構的開發視圖
05 場景視圖
場景視圖，即4+1中的1。從前面的圖可以看到，4+1中的4個視圖都是圍繞着場景視圖爲核心的。它用於描述系統的參與者與功能用例間的關係，反映系統的最終需求和交互設計。在UML中通常由用例圖表示：
