如何畫架構圖？

01-19

有什麼是一定要有的，又有什麼是不該有的？

軟體架構是一種無法以簡單的一維方式進行說明的複雜實體。
－Paul Clements 《軟體架構編檔》

正如上面提到的，不同的受眾，比如用戶、客戶、開發人員、測試人員、運維人員，需要從各自工作的角度去理解和使用架構。所以回答這個問題，需要首先了解這幅架構圖畫出來是給誰看，你想從那個維度去入手。

確定了這個問題之後，再來了解架構視圖有哪些維度和組成要素：

1. 架構視圖

最經典的當屬4+1視圖：

邏輯視圖
開發視圖
過程視圖
物理視圖
場景視圖

4+1視圖提出後，業界也有其它的觀點提出，諸如SEI(模塊視圖、組建和連接件視圖、分配視圖)、西門子4種視圖（概念、模塊、代碼、執行視圖）、以及RM-ODP(企業視圖、信息視圖、計算視圖、工程師圖）等。

常見的視圖除了上述4+1視圖外還包括：數據視圖、安全視圖、實現視圖等。

2. 了解架構視圖的四要素

圖示化主要元素和元素之間的關係
具有明確的圖例、定義和說明元素
每個元素具備明確的介面和行為規範
設計原理和設計決策的信息

3. 簡單說一下幾個視圖針對的角色和維度：

邏輯視圖一般針對客戶、用戶、業務人員、開發組織，主要從系統的功能元素、以及它們的介面、職責、交互維度入手。主要元素包括系統、子系統、功能模塊、子功能模塊、介面等。

開發視圖一般針對開發和測試相關人員，主要描述系統如何開發實現；主要元素包括描述系統的分層、分區、框架、系統通用服務、業務通用服務、類和介面、系統平台和大基礎框架。用途是知道開發設計和實現。

物理視圖一般針對系統運維人員、集成人員，它是系統邏輯組件到物理節點的映射，節點與節點間的物理網路配置等，主要關注非功能性需求，諸如性能（吞吐量）、可伸縮性、可靠性，可用性等，從而得出相關的物理部署結構圖。

4. 寫在最後

了解這些，確定了你的受眾和切入的維度後，你就可以決定你要用什麼樣的視圖和視圖組合來表達你的內容，挑選一個你得心應手的工具去實施就可以了。

在我看來，用白板和團隊一起畫出來是一件極美的好玩的事情。

個人觀點，僅供參考。

不請自來……簡單說，前面的回答說用PPT或者用PlantUML或者用visio，解決的都是個「用什麼工具畫」的問題，不是「怎麼畫」的問題。「怎麼畫」是個方法問題，在白紙上或者黑板上畫也是一樣的方法，有了方法才談得上工具。

直接上結論。程序員必讀之軟體架構 (豆瓣) 這本書就是解決「怎麼畫」這個問題的。需要哪些圖呢？第35章：「C4：語境、容器、組件和類」，這就是你需要的4個層面由高到低逐步細化的圖。

前面 @林孟同學給的那個圖問題在哪兒呢？就在它沒有統一的抽象層面。同一個圖上既在講大塊業務（考試中心業務），又在講具體服務（時間服務），也在講對象設計（DAO），還在講具體技術（JDBC）。沒有統一抽象層面的圖，就沒法針對特定讀者，業務看不懂，技術看了不過癮。

程序員必讀之軟體架構 (豆瓣) 這本書很不錯。讀它，這個問題就解決了。

yEd - Graph Editor 比較丑

ProcessOn - 免費在線作圖，實時協作在線工具，我現在還在用，還是很醜

https://www.draw.io/ 功能跟ProcessOn差不多，畫entity relation爽一點。

Gliffy | Online Diagram and Flowchart Software 很帥的工具，準備用

ASCIIFlow Infinity 這個很有逼格，但是功能太簡單了只能用來畫腦圖

我會在腦子裡先把層次，介面，資源，數據流都過一遍，輪廓清晰以後用紙筆畫出來，修改到覺得比較準確了再用軟體工具正式化。

PlantUML (PlantUML : Open-source tool that uses simple textual descriptions to draw UML diagrams.)

如果是要在linux下面話出專門的UML構架圖的話，可以使用這個工具，畫出的圖當然也是比較教科書一樣的風格啦。好處是可以直接和Markdown文檔整合在一起，這樣的話比較符合what you think is what you get 的思路。

如果您也像我一樣用emacs寫markdown然後再用pandoc快速的轉換成高可讀性文本的話，這個工具可以讓您工作更加順暢 kbonne/pandoc-plantuml-filter · GitHub

成品這裡有一個例子 pandoc-plantuml-filter/README.pdf at master · kbonne/pandoc-plantuml-filter · GitHub

這裡拿 @vczh 開玩笑啦～來個栗子

```plantuml
@startuml
馬甲 -&> 美女: 好看是什麼體驗？

美女 -&> 馬甲: 照片來啦
馬甲 -&> 輪子哥: 呵呵
輪子哥 -&> 美女: 加啦
@enduml
```

最近在寫一些跟實時機器學習，Docker等有關的筆記，不定時的會在自己家寶寶的微信公眾號碼上面放出經驗分享，大家有興趣的話可以掃描下面的二維碼關注哦：

http://weixin.qq.com/r/iUMnP4fEc9oMrcNc9xab (二維碼自動識別)

先畫腦圖，腦圖畫明白了，你自己就知道怎麼畫了

個人認為最常見的架構圖有兩類，一類是「運行時架構」，也就是描述程序在運行時有什麼進程，進程裡面有什麼模塊，進程之間怎麼交互，往往還有通信協議和鏈路這種，其他人提供的大多數這種。運行時架構圖往往關注的運行性能、承載量等運行效率問題，但是這種架構圖是遠遠不夠的，本人對此深惡痛絕。

另外一類是「代碼架構」，這種架構描述代碼模塊的關係，什麼代碼和什麼代碼是耦合的，他們的耦合形式是靜態的引用、繼承，還是動態的事件、消息隊列。這種架構圖才能真正指導代碼避免寫的很糟糕。但是真正用心去設計這種代碼架構的人太少，所以我們的軟體代碼往往都是一坨屎一樣。

自己畫得，菜鳥一枚僅作參考

我覺得目前的「架構」兩字，已經被玩爛了。在初級程序員的世界裡，所謂架構，不過是怎麼搭建一個可用的工程，選用什麼樣的框架。架構關注的維度無非有以下幾點：功能

性能、可擴展性、可用資源、分工。我們從一個架構應該具有的基本素質來看架構圖應該關注哪些方面。

夾狗屎職責：

1. 能夠對業務需求進行抽象，以工程思維進行描述

2. 能夠基於現有模型和現有基礎基礎工具進行抽象化，對業務需求進行分解

3. 提出可行性的整體解決方案，包括工程可能遇到的阻礙和瓶頸點

4. 在可用資源的基礎上盡量實現大多數業務需求

5. 在可預見的周期內支持系統的擴展性和線性擴容需求

6. 在整個項目周期中進行整體跟蹤和演進記錄，及時重構

ok，我們一條條來解釋，我們的架構圖需要哪些元素。

首先：

1. 需要一個對業務流程的抽象化過程，這一般使用普通的流程圖即可表達。這個是比較重要的一部分，因為它圈定了你的業務範圍和功能訴求，接下來你的設計也會圍繞著這個圈子轉

2. 針對需求方面，需要有模型和模式來支持。比如你的系統類似於一個JMS的非同步消息系統，或者有一個狀態模式的業務流轉圖，這些都需要你著重紀錄下來，它們是工程的骨骼，只有骨骼健壯，才能支撐更加豐富的功能特性。這個過程可以參考業界現有的成功模式，在此基礎上進行改進和創新。

3. 解決方案。模型和模式是比較重要的功能點，是時候將它們穿插組合起來了，一般的，架構級別的得到這部分圖，就可以大體把握整個工程了。這個也是PPT夾狗屎乾的事情

4. 細化每一個需求到工程圖，比如狀態圖類圖時序圖，以我的經驗來看，這部分可以只指出關鍵點，不是必要的，代碼的描述能力比圖形更形象，而且避免了同步問題。

5. 擴展圖。這個也需要體現在解決方案上，是PPt的一個比較重要的維度，如果你的系統不支持擴容和failover等特性，就不算是一個完善的系統。不管是使用現有的工具還是自建擴展，都需要提及。

6. 重構重構，看心情和時間出圖吧。

架構圖么，一個是工程化的（UML），一個是推廣化的（PPT）。圖並不是畫的越多越好，因為你還會面臨架構演變所造成的同步問題。反觀PPT，只提重點，讓人一目了然，知道你的大體設計思想，還是比較有含量的。所有如果你問我架構圖的標準是什麼，那麼不如像ppt架構師靠攏吧。

Flowchart Maker amp; Online Diagram Software確實是個好軟體

畫架構圖，用(ProcessOn - 免費在線作圖，實時協作) 。

畫架構圖的目的是為了把你對這個軟體的思想通過工具的方式以圖形來表達出來，說白了用什麼工具都無關緊要，最重要的是你對這個軟體的認識，怎麼來提高它的性能才是最關鍵的；了解一下UML的基礎知識就行了。

Rhapsody

要考慮你的讀者還有你想表達的內容。

誰會看，給領導看，給合作公司看，要拿去發表，公司內部技術交流，還是只是團體內討論？

表達出重點，想表現出關係，變化，架構調整，流程，介面定義？

工具不是重點，白板，或者紙筆最方便。

用visio的基本流程圖。