如何設計分層架構和互動介面 API ?

架構設計流程

在「  如何建立架構師的立體化思維？ 」這篇文章中，  跟大家一起聊到架構設計涉及業務、技術、系統和時間等幾個維度，也知道從技術維度可以將應用分成七層，那具體怎麼做呢？今天我們繼續來聊聊分層架構的設計流程，以及介面設計方法等內容。通常，我們可以將分層架構的設計流程分解為下列 4 個步驟：

1. 第一步，結合現實情況，將系統劃分成多個層次。
2. 第二步，確定層與層之間的關係，梳理出層與層之間的互動介面。
3. 第三步，將功能相近的介面劃歸到一個模組，確保模組高內聚，對外低耦合。
4. 第四步，在此基礎上進一步明晰介面的引數列表。

僅僅四個步驟就完成了架構設計嗎？這會不會太簡單空洞了呢？各位看官，不要著急，請聽蔡老師慢慢道來，每個步驟都有極具可操作性的方法及工具。

圖 5  架構設計流程

層次的切分方法

面對一個龐然大物，你該如何下手呢？不用擔心，這已經給你準備了庖丁解牛的方法，輕輕鬆鬆把一個複雜的大系統變得可以掌控了。

1. 第一刀：按照這套方法論來進行架構設計，最理想的情況是將 X 軸切分成七層。而第一刀應該先切在業務和領域之間，即透過 API 把兩邊解耦。互動和業務跟使用者關聯度高，經常隨需求變化而改動，而領域和資源相對比較穩定。
2. 第二刀：考慮到要完成某些業務功能，系統可能需要呼叫外部系統協同完成，為了保證領域層相對穩定，我們需要隔離外部系統或資料持久層變化帶來的影響，那第二刀應該切在領域和資源之間。
3. 第三刀：考慮到同樣的一個業務可能會有多套介面，例如有 Web 版、桌面版、移動版等，為了提高重用，隔離變更，那接下來要把互動和業務切開。

透過上面這 “ 溫柔的三刀 ” ，我們就可以把一個大塊頭切分成七個層次。

介面的設計方法

在確定分層之後，我們可以把每個業務需求的互動時序圖畫出來，而分層就是互動時序圖的主角。這時候我們就可以清晰的找出層與層之間的互動介面，以及可以初步確定每個介面的引數列表。

圖 6  業務互動時序圖

考慮到 API 、領域模型介面、 SPI 是最為關鍵的介面，那良好的設計就顯得更為重要。那如何能夠設計出良好的介面呢？在這點上，蔡老師也有非常豐富的經驗可以分享：

 

圖 7  介面設計流程圖

1. 找出領域物件：透過多輪領域訪談，與業務專家一起分析出領域物件。另外，也可以透過研究外部介面及資料字典來明晰領域物件，反過來也可以豐富外部介面和資料字典。
2. 設計領域模型、資源模型、資料模型：在挖掘領域物件的過程中，我們就可以開始設計領域模型了，確定領域物件之間的關聯關係。當關聯關係逐步清晰之後，我們還可以根據關聯關係的密集程度對領域物件的組織方式做一些調整，找出核心的領域物件集合，其他領域物件可以歸類到圍繞核心領域物件集合的衛星集合裡面。透過多輪調整，我們可以得到一個能夠對映業務、關係簡化的領域模型。然後兵分兩路啟動資源模型和資料模型的設計工作。上述三個模型之間的關係及區別，請參見下文。
3. 設計領域模型介面、 API 、 SPI 、資料庫：在設計領域模型介面時，我們要儘量做到不多不少，這些介面都是對外提供服務所必須的，也是全面的，並且粒度要細。在設計 API 時，我們要考慮內外客戶的需求和特點，做到方便易用，可以參考 RESTful API 設計相關的資料。在設計 SPI 時，我們要儘量隔離資源層對領域層的影響。

在完成上述工作之後，我們就可以進入實施階段，開始啟動代理層、核心層和服務層的程式碼設計工作。另外，如果是對線上已有系統進行升級，那還要開始制定資料的遷移計劃。

三個模型之間的關係及區別

1. 領域模型，對映特定業務領域當中核心領域物件及其關聯關係，這些物件及關係的存在都是完成業務規則所必須的，甚至是法律法規等明文要求的，不會輕易變動。
2. 資源模型，基於領域模型，從為內外客戶提供服務的角度分析定義出來的，包含了資源物件及其關聯關係。根據內外客戶的特點及需求，我們可以調整資源模型中的內容。
3. 資料模型，基於領域模型，從儲存（持久化或快取）資訊的角度分析定義出來的，包含資料物件及其關聯關係。根據儲存載體的特點及需求，我們可以調整資料模型中的內容。

先分享到這裡，堅持原創不易，如果你覺得有價值，麻煩動動手指點個 「 贊」，老兵哥會更有動力。另外，我還會持續分享職業規劃、應聘面試、技能提升、影響力打造等經驗， 關注 「   」， 賦能程式人生！