繪製硬體或軟體架構圖在組織中，最難的點就是要如何讓大家風格及語言一致。
也許透過繪製標準等，可以達到一定的成效。
但，不能就這樣滿足了。
傳統的系統或是軟體架構，可以透過一些架構圖繪製工具來達到效益，但當微服務時代時，應用這些UI 工具就會發現整個圖表重重交錯且牽一髮動全身，當要異動時發現太難就很容易停在該版本而變成蚊子館。
Diagrams as Code (DaC) 方案就是在於可以透過程式碼(YAML、DSL等都有)的方式來進行架構圖的繪製，並也因為as code 的原因，可透過Git等版控方式來進行歷程記錄演進，避免資料不同步而衍生的溝通障礙。
另外可以參考 IcePanel 大神的文章：
Top 7 diagrams as code tools for software architecture | by IcePanel | Medium
常用的架構圖標準推動進程
- 建立架構圖繪製標準，初期還是透過人工繪製為主
- 定義使用者關聯場域(例如：資料中心、外部顧客環境、內部辦公環境等，建議以建築物或區域為標準)
- 定義使用者類型(例如：外部顧客、IT維護人員、業務操作人員等)
- 於場域區塊中放入設備資訊(例如：Web、AP、DB Server等)
- 各設備資訊間的串接協定(例如：HTTPS、SMB、SSH等)
- 各設備資訊的節點數量(例如：Web Server 放了5台做NLB等)
- 定義各設備資訊間的傳遞內容(選用，但如呈現可讓架構資訊更為透明)
- 標示各設備存放的網路區域(選用，如企業有做網段Zone區隔才會用到)
- 資訊人員透過Diagrams as Code (DaC)的方式，讓產出的架構圖產出物能風格且標準一致
- 讓使用者透過頁面進行業務情境編輯，產出初級架構圖後供資訊人員做微調修改
- 情境如：業務分析人員於表單中選擇情境 “A系統提供外部顧客服務”、”預計TPS 10000″等
- 備註：這邊應該會有一段時間的磨合時期
- 進展到成熟的架構圖後，就可以在搭配IaC 等進行資源建置，甚至連動Threat Modeling 或是Loading Test 等來驗證架構。
Diagrams 是一個我很愛的一個工具(圖表 ·圖表即代碼 (mingrammer.com)
( 以下為官方範例，包含對於icon 等標準，都可一併定義完成且去呼叫應用)
from diagrams import Cluster, Diagram
from diagrams.k8s.compute import Pod, StatefulSet
from diagrams.k8s.network import Service
from diagrams.k8s.storage import PV, PVC, StorageClass
with Diagram("Stateful Architecture", show=False):
with Cluster("Apps"):
svc = Service("svc")
sts = StatefulSet("sts")
apps = []
for _ in range(3):
pod = Pod("pod")
pvc = PVC("pvc")
pod - sts - pvc
apps.append(svc >> pod >> pvc)
apps << PV("pv") << StorageClass("sc")
歸根究底，資訊架構的透明化，才能有助於前期規劃及分析討論。