如何建立架構師的立體化思維？

從程式設計師往架構師轉型的路上，蔡學鏞老師總結的“四維架構設計方法論”對我頗有幫助，讓我對架構設計有了更立體化、系統化的認知，現將學習心得分享出來供需要的小夥伴參考。

這套方法論透過空間（ 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 軸的另外一個業務系統時，兼顧效率和耦合，這套架構設計方法論給出了具體的架構原則：

1. 當被呼叫的是公共系統時，那麼呼叫將被視為內部呼叫，即服務可以直接呼叫服務。考慮到公共系統比較穩定，不會經常改變，直接呼叫可以減少呼叫環節，保障效率。
2. 當被呼叫的是非公共系統時，那麼呼叫將會被視為外部呼叫，即透過代理層去呼叫被呼叫系統的對外服務介面。這相當於把兩個系統後臺進行了串聯，降低了系統之間的耦合，後續被呼叫系統發生變更，對呼叫系統的影響也可以藉由其代理層進行了隔離。

圖 3 Y 軸不同業務系統之間呼叫關係  

系統維度（ Z1...Zn ）

該維度主要關注軟體、容器、執行時、作業系統、虛擬機器、到硬體等這些與業務無關係統的架構。 Z 軸的系統可以分別用於前端最佳化、應用最佳化、平臺最佳化、資源最佳化等層面。

圖 4 Z 軸分層結構

時間維度（ T1 … Tn ）

對於一個新產品來說，架構不是一次成型的，從初始到成熟要經過一個不斷演進的過程。對於一個已有產品來說，架構的最佳化也是要結合實際情況分步驟實施。除了技術上的考慮之外，我們還需要考慮市場及投資等方面的情況。

通常，在研發的初期，產品本身的定位還不太清晰，需要快速地迭代投放市場獲取先發優勢，以及驗證想法，不斷地明確產品的定位。這個階段產品需求變動非常頻繁，許多架構的驅動因素尚未明確，如果過於關注架構，那產品推向市場就會遙遙無期。隨著產品定位的逐步清晰，架構的驅動因素及約束條件都逐漸浮出水面，這個時候架構設計的重要性就顯現出來了。另外，我們還需要根據投資預算來調整架構設計。如果投入比較充裕，那我們就可以投入更多的人力來提前將架構驅動因素研究清楚，甚至可以針對不確定的約束提供多套備選方案。

先分享到這裡，後續我還會繼續分享各個維度的架構設計心得，請感興趣的小夥伴記得關注哦！ 原創不易，如果你覺得有價值，麻煩動動手指點個 「  贊 」，老兵哥會更有動力。另外，我還會持續分享職業規劃、應聘面試、技能提升、影響力打造等經驗，  關注  「    」，  賦能程式人生 ！