工作兩三年了，整不明白架構圖都畫啥？

但是偏理科程式碼邏輯或架構設計，只能把抽象的內容用圖表的形式展現出來，讓大家在同一的共識下共同協同工作。

而我們畫的架構圖、流程圖、結構圖、功能 ... 技術文章»工作兩三年了，整不明白架構圖都畫啥？ 工作兩三年了，整不明白架構圖都畫啥？ 2021-03-0212:00:50 作者：小傅哥部落格：https://bugstack.cn 沉澱、分享、成長，讓自己和他人都能有所收穫！😄 一、前言 很多程式設計師畫架構圖頭疼，不知道畫什麼、怎麼畫！ 分享、評審、述職、答辯，只要你在程式設計師這個行業，就幾乎離不開要畫圖。

一提到畫圖很多人就想站會起來喊，」內卷「、」內卷啦「、」PPT工程師「，但程式程式碼本身就是一種數學邏輯的具體實現，如果沒有一些圖表配合文字的闡述，講真很難讓所有人都能在共同的共識下進行交流。

這不像是文科，」八表流雲澄夜色，九霄華月動春城「上來就能聯想到它是在描述啥。

但是偏理科程式碼邏輯或架構設計，只能把抽象的內容用圖表的形式展現出來，讓大家在同一的共識下共同協同工作。

而我們畫的架構圖、流程圖、結構圖、功能圖、邏輯圖等，都需要好看、好懂、好用、好搞，因為： 好看是為了提升溝通效率，好懂是為了提升交流共識，好用是為了提升交付品質，好搞是為了提升實施速度。

這就像君子在追求漂亮姑娘一樣，好看就想主動撩一下、有品行和共同的三觀很快讓你開口說我懂你、接下來就是交付品質和實施速度了，那也是水到渠成的事。

好，別激動，接下來我們就開始專心研究研究架構圖，都有哪些，該怎麼畫，有什麼手法。

二、架構圖有哪幾種？ 僅說技術架構圖的話，通常我們☞指的是選型各項技術元件來支撐整個服務建設的系統架構。

但用於不同人群範圍和不同場景下會有其他分類，如圖26-1架構圖分類 業務架構：需求初期業務的結果和過程描述一般比較模糊，可能來自於某個老闆、運營或使用者的反饋。

客戶說海爾洗衣機洗土豆會堵，海爾立馬設計專門的土豆洗衣機業務方向往往是定方向和結果的叫戰略，主要包括業務規劃、業務模組和流程以及問題域的列表等。

應用架構：服務複用、跨組協同，簡單、靈活、整合是應用架構必須考慮的點，就像你要上線一個聊天功能，那麼聊天內容的輸入法、文字識別、輿情監控以及視訊服務、支付服務等，它們都是在應用架構分層下沉澱到平臺的產物，在供各個方使用。

產品架構：業務提需求，產品定方案，相對於業務的粗放流程，產品架構會更加細膩以及考慮各個模組的分層和邊界。

資料架構：資料的獲取、資料的存放和資料的使用是資料架構要解決的三個問題，資料庫存放、巨量資料彙總、資料分析等。

技術架構：是離程式設計師最近的架構設計，它不僅是系統搭建的架構圖設計，還包括了結構、功能、流程、邏輯等內容。

它的具體描述就是整個系統如何落地的具體實現方案。

三、Zachman框架是什麼？ Zachman框架，由約翰扎科曼（JohnZachman）在1987年創立的全球第一個企業架構理論，其論文《資訊系統架構框架》至今仍被業界認為是企業架構設計方面最權威的理論。

Zachman框架（Zachmanframework）是一種邏輯結構，它可以對企業資訊按照不同分類和不同角度進行表示。

Zachman框架，從橫向六個角度看待企業，這個六個觀點可以分為；什麼內容、如何工作、什麼地點、誰負責、為什麼這麼做（稱為W5H）。

框架的列由一組工件組成，分為規劃者、擁有者、設計者（架構師）、建造者、分包者、產品，或者有時表示為視點：範圍上下文，業務概念，系統邏輯，技術，物理，元件組裝和操作類。

整體如圖26-2TOGAFZachman框架 表格橫向六項代表了用於描述資訊系統的某一個方面，對於任何一個事物只要在這幾個基本方面對其進行清洗的解釋就足夠可以描述清楚。

資料（What，即什麼內容）：什麼是業務資料，資訊或物件？功能（How，即如何工作）：業務如何運作，即什麼是業務流程？網路（Where，即何處）：企業運營、部署在哪裡？人（Who，即何人負責）：什麼人？什麼是業務部門及其等級制度？時間（When，即什麼時間）：業務計劃和工作流程是什麼？什麼時候執行？原因（Why，即為什麼做）：為什麼選擇的解決方案？這是怎麼產生的？ 表格縱向六項代表了在資訊系統構造過程中所涉及到的人在描述資訊系統時所採用的視角，包括： 範圍/規劃者（Planner）：此檢視描述了業務目的和策略，充當其他檢視將被派生和管理的上下文。

業務模型/擁有者（Owner）：這是對資訊系統必須在其中運作的組織的描述。

系統模型/設計師（Designer）：該檢視概述了系統如何滿足組織的資訊需求。

技術模型/建造者（Builder）：這是系統如何實施的表示，它使特定的解決方案和技術顯而易見。

詳細表述/分包者（Sub-Contractor）：這些表示說明了某些系統元素的特定於實現的細節：在生產開始之前需要進一步說明的部分。

功能系統/產品（FunctioningEnterprise）：在1987年的論文（《Aframeworkforinformationsystemsarchitecture》）中並沒有這一行的內容，實際上此行的內容也並不在架構描述的範疇的之內，不過為了使得架構Zachman框架對於架構的表述更加完備，這一行最終還是被加了進去。

根據TOGAF的定義，企業是具有一系列共同目標組織的集合，而架構則是為了有效地實現這一系列目標。

在實現的過程中定義了企業的結構和運作模式的概念藍圖（SearchCIO），以及構成企業的所有關鍵元素和其關係的綜合描述（Zachman）。

通過建立、溝通和優化用以描述企業未來狀態和發展的關鍵原則和模型以將業務願景和戰略轉化成有效的企業變更的過程（Gartner）。

可以這一部分內容會比較繞，但可以作為架構設計的知識擴充套件進行學習理解以及運用。

四、陪你畫個架構圖 簡單來說，架構圖就是為了達成交流共識的實現方案演示，並不一定非得拘泥於某種形式，只要你能畫的清楚，講的明白就最合適不過了。

1.架構選型圖 難度：⭐⭐⭐作用：通常在新專案開發初期，都要做一些技術選型工作。

在負載、閘道器、架構、治理、框架、服務、資料以及環境和支撐服務上，要選擇適合當前開發的技術。

2.微服務架構 難度：⭐⭐⭐⭐作用：技術選型完畢後，接下來就是對於這些技術的運用。

這個過程有點像搭積木一樣，把每一個區域用適合此位置的積木填充進去。

如果是團隊初建或者是技術升級，那麼這個過程還是比較複雜的，需要大量的驗證。

不過其實網際網路的技術分層和使用已經相對穩定，搭建一個這樣的微服務並不會耗費太長的時間。

3.技術架構圖 難度：⭐⭐⭐⭐作用：技術架構圖主要是對於研發層面做技術實現指導的，它可以把系統分層和實現結構劃分清楚。

另外一般也會把案例工程的結構拿出來一起講解，這樣可以讓團隊夥伴快速的進入開發。

五、總結 本章節向大家講解了什麼是架構圖，架構圖的分類和怎麼畫架構圖，通過這樣的內容可以讓大家對架構圖有一個全貌的認知。

在以後自己畫架構圖了也可以非常明確的知道面對的什麼使用者群體，要畫的內容是什麼。

TOGAF有一套非常完善的企業架構理論，它描述了一種開發和管理企業體系結構生命週期的方法，並構成了TOGAF的核心。

所涉及到的知識非常豐富，值得認真看一下。

好看，能把一件事做的好看非常重要，好看能讓人提起興趣、好看可以使溝通成本降低。

也鼓勵大家儘可能把經過自己手裡的東西，做的好看一些。

六、系列推薦 方案設計：基於IDEA外掛開發和位元組碼插樁技術，實現研發交付品質自動分析技術掃盲：關於低程式碼程式設計的可持續性交付設計和分析數學，離一個程式設計師有多近？半年招聘篩選了400+份簡歷，告訴你怎麼寫容易被撩！90%的程式設計師，都沒用過多執行緒和鎖，怎麼成為架構師？ 小傅哥 CSDN認證部落格專家 ASM 設計模式 面經手冊 一線網際網路軟體開發工程師，擅長編寫優秀的程式碼、中介軟體開發、架構設計等。

|公眾號：bugstack蟲洞棧，回覆：設計模式、面經手冊、位元組碼程式設計，可以下載我的PDF！