架構設計流程
在「 如何建立架構師的立體化思維？ 」這篇文章中，老兵哥 跟大家一起聊到架構設計涉及業務、技術、系統和時間等幾個維度，也知道從技術維度可以將應用分成七層，那具體怎麼做呢？今天我們繼續來聊聊分層架構的設計流程，以及接口設計方法等內容。通常，我們可以將分層架構的設計流程分解爲下列 4 個步驟：
- 第一步，結合現實情況，將系統劃分成多個層次。
- 第二步，確定層與層之間的關係，梳理出層與層之間的交互接口。
- 第三步，將功能相近的接口劃歸到一個模塊，確保模塊高內聚，對外低耦合。
- 第四步，在此基礎上進一步明晰接口的參數列表。
僅僅四個步驟就完成了架構設計嗎？這會不會太簡單空洞了呢？各位看官，不要着急，請聽蔡老師慢慢道來，每個步驟都有極具可操作性的方法及工具。
圖5 架構設計流程
層次的切分方法
面對一個龐然大物，你該如何下手呢？不用擔心，這已經給你準備了庖丁解牛的方法，輕輕鬆鬆把一個複雜的大系統變得可以掌控了。
- 第一刀：按照這套方法論來進行架構設計，最理想的情況是將X軸切分成七層。而第一刀應該先切在業務和領域之間，即通過API把兩邊解耦。交互和業務跟用戶關聯度高，經常隨需求變化而改動，而領域和資源相對比較穩定。
- 第二刀：考慮到要完成某些業務功能，系統可能需要調用外部系統協同完成，爲了保證領域層相對穩定，我們需要隔離外部系統或數據持久層變化帶來的影響，那第二刀應該切在領域和資源之間。
- 第三刀：考慮到同樣的一個業務可能會有多套界面，例如有Web版、桌面版、移動版等，爲了提高重用，隔離變更，那接下來要把交互和業務切開。
通過上面這“溫柔的三刀”，我們就可以把一個大塊頭切分成七個層次。
接口的設計方法
在確定分層之後，我們可以把每個業務需求的交互時序圖畫出來，而分層就是交互時序圖的主角。這時候我們就可以清晰的找出層與層之間的交互接口，以及可以初步確定每個接口的參數列表。
圖6 業務交互時序圖
考慮到API、領域模型接口、SPI是最爲關鍵的接口，那良好的設計就顯得更爲重要。那如何能夠設計出良好的接口呢？在這點上，蔡老師也有非常豐富的經驗可以分享：
圖7 接口設計流程圖
- 找出領域對象：通過多輪領域訪談，與業務專家一起分析出領域對象。另外，也可以通過研究外部接口及數據字典來明晰領域對象，反過來也可以豐富外部接口和數據字典。
- 設計領域模型、資源模型、數據模型：在挖掘領域對象的過程中，我們就可以開始設計領域模型了，確定領域對象之間的關聯關係。當關聯關係逐步清晰之後，我們還可以根據關聯關係的密集程度對領域對象的組織方式做一些調整，找出核心的領域對象集合，其他領域對象可以歸類到圍繞核心領域對象集合的衛星集合裏面。通過多輪調整，我們可以得到一個能夠映射業務、關係簡化的領域模型。然後兵分兩路啓動資源模型和數據模型的設計工作。上述三個模型之間的關係及區別，請參見下文。
- 設計領域模型接口、API、SPI、數據庫：在設計領域模型接口時，我們要儘量做到不多不少，這些接口都是對外提供服務所必須的，也是全面的，並且粒度要細。在設計API時，我們要考慮內外客戶的需求和特點，做到方便易用，可以參考RESTful API設計相關的資料。在設計SPI時，我們要儘量隔離資源層對領域層的影響。
在完成上述工作之後，我們就可以進入實施階段，開始啓動代理層、核心層和服務層的代碼設計工作。另外，如果是對線上已有系統進行升級，那還要開始制定數據的遷移計劃。
三個模型之間的關係及區別
- 領域模型，映射特定業務領域當中核心領域對象及其關聯關係，這些對象及關係的存在都是完成業務規則所必須的，甚至是法律法規等明文要求的，不會輕易變動。
- 資源模型，基於領域模型，從爲內外客戶提供服務的角度分析定義出來的，包含了資源對象及其關聯關係。根據內外客戶的特點及需求，我們可以調整資源模型中的內容。
- 數據模型，基於領域模型，從存儲（持久化或緩存）信息的角度分析定義出來的，包含數據對象及其關聯關係。根據存儲載體的特點及需求，我們可以調整數據模型中的內容。
先分享到這裏，堅持原創不易，如果你覺得有價值，麻煩動動手指點個 「贊」，老兵哥會更有動力。另外，我還會持續分享職業規劃、應聘面試、技能提升、影響力打造等經驗，關注 「 IT老兵哥 」，賦能程序人生！
近期文章索引：