如何設計分層架構和交互接口 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. 數據模型，基於領域模型，從存儲（持久化或緩存）信息的角度分析定義出來的，包含數據對象及其關聯關係。根據存儲載體的特色及需求，咱們能夠調整數據模型中的內容。

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

近期文章索引：

• 程序員，怎麼成了一碗青春飯？
• 爲何要成爲「無敵」程序員？
• 程序員，怎樣打造我的影響力？
• 程序員打造影響力常犯的3個錯
• 從程序員到架構師的技能圖譜