如何落地業務建模(4) 將模型實作為RESTful API

• 什么風格的API適合作為模型API
  • 行為角度
  • 資料角度
• 將模型映射為RESTful API
  • 1.通過URI表示領域模型
  • 2. 根據URI設計API
  • 3.使用分布式超媒體設計API中涉及的資源
  • 4. 使用得到的API去覆寫業務流程，驗證API的完整性

DDD受到行業熱捧的一個原因是：它設法尋找到一個在軟體系統生命周期內穩固不變的點，由它構成架構、協同、交流的基礎，幫助我們更好的應對軟體中的不確定性，
而API作為對外暴露的介面，也是需要保持高穩定性的組件，最好能像領域模型一樣穩定，于是通過領域模型驅動獲得API的設計（Domain Model Driven API Desin），就成了一種非常自然的選擇，

什么風格的API適合作為模型API

要從資料角度，而不是行為角度去構建API，這樣可以保證構建的API能夠和領域模型結合地更加緊密，

繼續以極客時間為例，如果從行為角度去構建API，可以參考催化劑的模型，因為這種建模方法中包含了互動：

行為角度

從行為角度去設計API，那么會著眼于從人機互動上入手，尋找系統提供了什么服務，并針對這些服務進行API設計，結果類似這樣：

SendGift(...)
SubscriptionColumn(...)
RegisterUser(...)
ReadColumn(...)
RateColumn(...)

這種API風格被稱為PRC風格(Remote Procedure Call Style)，在1980年代逐漸成為分布式系統的默認風格，優點是簡單直接，提供什么功能都在介面里說清楚了；但從模型的角度講，除非嚴格使用催化劑方法，否則RPC風格與模型之間有所隔閡，結合地不夠緊密，表現在：

• RPC的方法名并不來自于領域物件，互動是一種我們將隱藏在領域模型中的業務維度展開的方法，因為從互動入手，獲得的RPC風格API并不是源自領域模型的，而是源自其它業務維度的；
• RPC風格的API訊息與回傳資訊通常也與領域模型無關，而是圍繞著互動給出的具體反饋，比如例子中的ReadColumn介面，其回傳值一般只包含對應篇章的內容，而不包含與之關聯的作者資訊，

資料角度

換一個角度看待互動行為：在操作之后，對互動背后的模型帶來了什么樣的改動，
怎么表示這些API呢？可以先使用URI表示需要修改的物件，然后再說明我們希望這個物件發生什么樣的改變，
比如/users表示系統中所有的用戶，那么注冊新用戶，就是新增一條資料，可以用POST /users表示，
通過URI與標準HTTP方法，就可以從資料角度構造與RPC等價的API，模型是從資料變化的角度描述業務的，具體的業務流程反而被隱藏了，那么從資料角度去構造API，自然比從行為角度出發更符合領域模型的特點，
RPC風格實際上是面向程序的編程風格，資料中沒有邏輯，要通過程序完成對資料的操作，而資料風格的API，則更多是面向物件風格，

RESTful API是為數不多的從資料角度描述API的方法之一，我們選擇它來進行領域驅動API設計，

將模型映射為RESTful API

將領域模型映射為RESTful API，可以按這四步進行：

1. 通過URI表示領域模型
2. 根據URI設計API
3. 使用分布式超媒體設計API中涉及的資源
4. 使用得到的API去覆寫業務流程，驗證API的完整性

1.通過URI表示領域模型

URI的路徑可以看做是對某種層次結構遍歷的結果，比如/users/愛學習的魚玄機/subscriptions，就可以認為是對下面的圖結構右側分支遍歷的結果：

這個圖實際上是將User-Subscriptions聚合進行實體化之后，再將實體與領域物件結合在一起得到的：

那么看到路徑/users/愛學習的魚玄機/subscriptions或者它的模板化形式/users/{user_id}/subscriptions時，就可以還原出路徑背后的領域模型，也就是User-Subscriptions的一對多聚合關系，
通過實體化方式，將領域模型展開成物件圖，然后在這種物件圖上遍歷，就能得到可以表示領域模型的URI路徑模板，當然，在理解了實體化與領域模型之間的關系后，也可以直接從領域模型出發來設計URI，
這個程序主要依賴聚合關系，所以需要在領域模型中尋找聚合邊界，
比如極客時間專欄的領域模型中，存在兩個聚合邊界：

1. 以User為聚合根的User-Subscriptions聚合
2. 以Author為聚合根的Author-Column-Content聚合

對于User-Subscriptions聚合，可以設計如下URI模板

1. /users User聚合根，表示系統中的全部用戶
2. /users/{uid} User的實體化
3. /users/{uid}/subscriptions，User-Subscriptions聚合，表示某個用戶的全部訂閱
4. /users/{uid}/subscriptions/{sid} User和Subscription的實體化

其中，1、3表示集合邏輯，無需實體化；2、4表示物體邏輯，需要實體化模型，將它們從概念具象化到某個特定的個體，

2. 根據URI設計API

在根據領域模型得到了URI模板后，就需要圍繞著URI進行API設計了，程序比較簡單，只需構造這樣一張表格，表格中包含：角色、HTTP方法、URI、業務場景，

然后只需填入角色、URI，然后按照窮舉法，填入所有的HTTP方法，比如對于/users/{uid}/subscriptions，可以有四行，分別對應GET\POST\PUT\DELETE，
下一步就是尋找業務方反饋，幫助我們判斷這些由HTTP方法和URI組成的行為是否存在合理的業務場景，
比如經過討論，認為/users/{uid}/subscriptions的PUT、DELETE不存在業務場景，

這個程序與角色=目標-物體法類似，其中業務場景是目標，物體則是通過URI表示的領域模型，所以這樣的API建模程序，同時也在幫助我們展開業務維度，更好地將領域模型作為統一語言，

3.使用分布式超媒體設計API中涉及的資源

RESTful API風格

RESTful API是指符合REST架構風格的API設計，而REST架構風格是對互聯網規模架構的提煉與總結，這一切源自Roy Fielding提出的一個問題：既然互聯網是人類迄今為止構造的最大的軟體應用，那么到底是什么樣的結構原則，支撐了如此規模的異構且互聯的系統呢？我們能從中學習到什么，以幫助我們更好地構建軟體？
Roy Fielding將互聯網定義為分布式超媒體資訊獲取系統，是由超媒體描述的、分布式的資訊系統，在這個系統中，資訊分布在不同的服務器中，并由超媒體聯通，換句話說：分布式超媒體是互聯網的集成策略，

分布式超媒體

分布式超媒體可以實作客戶端與服務器之間的漸進式服務消費(Progressive Service Consumption)，在客戶端的多樣性和API的穩定性之間，取得了完美的平衡，
在智能手機流行前，大部分手機瀏覽器不具備完整執行js的能力，從技術角度講，CSS、JS都可以看做是對當前頁面的增強，CSS增強了當前頁面的視覺效果、JS增強了當前頁面的互動，
假設極客時間專欄的某篇文章，文本形式是默認服務，此外還有音頻、視頻形式的增強服務，那么可以在超媒體格式中這樣描述這些關聯資源：

<article>
    <title>***</title>
    <p>...</p>
    <link href="https://www.cnblogs.com/zhixin9001/p/.../chapter11.mp3" rel="voice">
    <link href="https://www.cnblogs.com/zhixin9001/p/.../chapter11.mp4" rel="video">
</article>

如果現在有三個客戶端，分別是閱讀器、聽書播放器、視頻播放器，那么這些客戶端就可以根據超媒體拿到自己需要的服務資源而忽略其它資源，

通過使用超媒體，可以用同樣的API，支撐起完全不同的客戶端，通過超媒體描述的增強服務，讓客戶端與服務器之間形成了一種協商與匹配的關系，客戶端按需索取，

使用分布式超媒體設計API資源

超媒體有兩個構成要素，只要具備這兩個要素，都可以看做超鏈接，比如html中的link：

1. 指向關聯資源的鏈接（href）
2. 與主資源的關聯關系（rel）

json格式沒有提供默認的鏈接格式，而Internet的一個標準提案HAL(Hypertext Application Language)對此做了定義，
JSON HAL規范示例：

{
    "_links":{
        "self":{"href":"/users/1"},
        "subscriptions":{"href":"/users/1/subscriptions"},
    },
    "username":"fakeUser"
}

這里self表明獲取當前資源的uri，也是PrimaryURI，和ID等價，可以作為 當前資源的識別符號，也可以用于快取，這里self的作用還不明顯，但如果是/users資源，那么只能通過self的地址來獲取某個user的詳情，
subscriptions表示了User-Subscriptions聚合關系，對于聚合根而言，需要為所有的聚合物件提供鏈接，
借助這種方式，可以將常用資料與全量資料設計成漸進式消費的兩種不同服務，再配合快取，性能也不會受太大影響，REST架構大量依賴快取來緩解性能問題，能否有效地利用快取會決定REST架構的成敗，所以在構造資源的時候，也需要將快取當做必須考慮的特性，詳加設計，

互聯網架構的精髓：服務器永遠不需要考慮客戶端的需求，把客戶端的額外需求，當做漸進式服務消費的需求，只需要提供對應的鏈接，剩下的就交給客戶端自行處理，通過將集成與訂制推向客戶端，從而保證服務端的穩定，

4. 使用得到的API去覆寫業務流程，驗證API的完整性

最后一步就是，將API作為模型的另一種表現形式，將其映射回所需支撐的業務流程之中，與業務方一起驗證這些API是否能夠滿足所有的需求，

參考資料
極客時間：如何落地業務建模 徐昊

標籤：領域驅動設計

上一篇：在頁面或存檔頭中顯示ACF欄位

下一篇：開閉原則