從程式員往架構師轉型的路上，蔡學鏞老師總結的“四維架構設計方法論”對我頗有幫助，讓我對架構設計有了更加立體化、系統化的認知，現將學習心得分享出來給需要的小伙伴參考。這套方法論通過空間（X、Y、Z）三個維度及時間T維度將問題域解構成可以輕鬆應對的小方塊，分而治之。同時，空間（X、Y、Z）三個維度聯動，... ...
從程式員往架構師轉型的路上，蔡學鏞老師總結的“四維架構設計方法論”對我頗有幫助，讓我對架構設計有了更立體化、系統化的認知，現將學習心得分享出來供需要的小伙伴參考。
這套方法論通過空間（X、Y、Z）三個維度及時間T維度將問題域解構成可以輕鬆應對的小方塊，分而治之。同時，空間（X、Y、Z）三個維度聯動，專門為單個維度解決不了的問題提供解決方案。時間 T 維度將問題分解到一個時間範圍內，分步驟按節奏逐一解決。多維度、立體化、分層次、動態演進，這是我對這套方法論特點的總結。接下來，讓我們進入這個四維的架構時空一探究竟！
圖1 四維座標系統
前後端維度（X1 … X7）
前後端維度被分解為交互、業務、領域、資源四大層，其中業務可以細分為應用X2、框架X3，領域可以細分為服務X4、核心X5，資源也可以細分為代理X6、數據X7，共分為七個層次。服務X4可以實現API，如果公開，就是開放介面，調用服務層的介面，通常需要授權。代理X6可以實現SPI，隔離耦合，避免核心X5 依賴特定的外部系統或資料庫。每個層次做到高內聚，層與層之間做到低耦合。
圖2 X軸分層結構
在系統實現過程中，可以綜合考慮現狀，X2應用和X3框架可以不分拆，X4服務和X5核心可以不分拆，待後續時機成熟可以再重構分層，這樣變更範圍僅在內部。
表2 X軸七層架構模型及其定位
|
分層類型 |
分層名稱 |
顏色 |
代號 |
分層定位 |
|
交互 |
界面層 |
紅 |
X1 |
界面更像是用戶的延伸，而非應用的延伸。界面可被視為用戶代理。根據用戶喜好、語言、平臺（手機、電腦、平板等）開發各種用戶界面。 |
|
業務 |
應用層 |
橙 |
X2 |
一個應用可以有多個界面，根據市場需求，開發各種應用，並以介面的方式展現。 |
|
框架層 |
黃 |
X3 |
將常用的應用流程設計成框架，後續開發同類型應用時，只要通過參數或者 DSL，就可以輕易訂製應用，減少開發成本。框架也可以用介面的方式開放讓外部調用。 |
|
|
領域 |
服務層 |
綠 |
X4 |
服務層針對領域對象進行操作，並提供彈性的調用介面。服務層介面通常數目不多，但每個介面通常參數相當多。服務層沒有狀態，也不做緩存。 |
|
核心層 |
藍 |
X5 |
核心層反映領域模型，核心層的介面基本就是對此領域模型進行操作。建立領域模型，一方面幫助介面設計，另外一方面幫助數據存儲設計，梳理出彈性的存儲方式。 |
|
|
資源 |
代理層 |
靛 |
X6 |
具備下列作用：數據代理，代表外部系統或資料庫；緩存，為了效率或提高可用性（當外部系統掉線）；數據模塊，支持讀寫分離；轉接或轉發，轉接到外部系統，轉發到日誌系統；數據備份系統（通過事件鉤子）；熱備系統接入。 |
|
數據層 |
紫 |
X7 |
數據是公司最重要的資產。根據數據的特性，資料庫可以是：關係式資料庫；列資料庫；Associative DB；Key-Value；文件資料庫；日誌。 |
業務維度（Y1 ... Yn）
從業務維度進行劃分，按照業務類型對系統進行分類。業務系統的劃分更多依賴業務領域的知識，這個維度設計最常用的方法論就是領域驅動設計DDD。
當Y軸的一個業務系統需要調用Y軸的另外一個業務系統時，兼顧效率和耦合，這套架構設計方法論給出了具體的架構原則：
- 當被調用的是公共系統時，那麼調用將被視為內部調用，即服務可以直接調用服務。考慮到公共系統比較穩定，不會經常改變，直接調用可以減少調用環節，保障效率。
- 當被調用的是非公共系統時，那麼調用將會被視為外部調用，即通過代理層去調用被調用系統的對外服務介面。這相當於把兩個系統後臺進行了串聯，降低了系統之間的耦合，後續被調用系統發生變更，對調用系統的影響也可以藉由其代理層進行了隔離。
圖3 Y軸不同業務系統之間調用關係
系統維度（Z1...Zn）
該維度主要關註軟體、容器、運行時、操作系統、虛擬機、到硬體等這些與業務無關係統的架構。Z軸的系統可以分別用於前端優化、應用優化、平臺優化、資源優化等層面。
圖4 Z軸分層結構
時間維度（T1 … Tn）
對於一個新產品來說，架構不是一次成型的，從初始到成熟要經過一個不斷演進的過程。對於一個已有產品來說，架構的優化也是要結合實際情況分步驟實施。
除了技術上的考慮之外，我們還需要考慮市場及投資等方面的情況。通常，在研發的初期，產品本身的定位還不太清晰，需要快速地迭代投放市場獲取先發優勢，以及驗證想法，不斷地明確產品的定位。這個階段產品需求變動非常頻繁，許多架構的驅動因素尚未明確，如果過於關註架構，那產品推向市場就會遙遙無期。隨著產品定位的逐步清晰，架構的驅動因素及約束條件都逐漸浮出水面，這個時候架構設計的重要性就顯現出來了。另外，我們還需要根據投資預算來調整架構設計。如果投入比較充裕，那我們就可以投入更多的人力來提前將架構驅動因素研究清楚，甚至可以針對不確定的約束提供多套備選方案。
今天先分享到這裡，後續我還會繼續分享各個維度的架構設計心得，請感興趣的小伙伴記得關註哦！堅持原創寫作不易，如果你覺得有價值，麻煩動動手指點個 「贊」，老兵哥會更有動力堅持。另外，我還會持續分享職業規劃、應聘面試、技能提升、影響力打造等經驗，關註 「 IT老兵哥 」，賦能程式人生！
近期文章索引：
