- 什麼風格的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設計，結果類似這樣：
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，可以按這四步進行：
- 通過URI表示領域模型
- 根據URI設計API
- 使用分布式超媒體設計API中涉及的資源
- 使用得到的API去覆寫業務流程，驗證API的完整性
URI的路徑可以看做是對某種層次結構周遊的結果，比如/users/愛學習的魚玄機/subscriptions，就可以認為是對下面的圖結構右側分支周遊的結果：
這個圖實際上是将User-Subscriptions聚合進行執行個體化之後，再将執行個體與領域對象結合在一起得到的：
那麼看到路徑/users/愛學習的魚玄機/subscriptions或者它的模闆化形式/users/{user_id}/subscriptions時，就可以還原出路徑背後的領域模型，也就是User-Subscriptions的一對多聚合關系。
通過執行個體化方式，将領域模型展開成對象圖，然後在這種對象圖上周遊，就能得到可以表示領域模型的URI路徑模闆。當然，在了解了執行個體化與領域模型之間的關系後，也可以直接從領域模型出發來設計URI。
這個過程主要依賴聚合關系，是以需要在領域模型中尋找聚合邊界。
比如極客時間專欄的領域模型中，存在兩個聚合邊界：
- 以User為聚合根的User-Subscriptions聚合
- 以Author為聚合根的Author-Column-Content聚合
對于User-Subscriptions聚合，可以設計如下URI模闆
- /users User聚合根，表示系統中的全部使用者
- /users/{uid} User的執行個體化
- /users/{uid}/subscriptions，User-Subscriptions聚合，表示某個使用者的全部訂閱
- /users/{uid}/subscriptions/{sid} User和Subscription的執行個體化
其中，1、3表示集合邏輯，無需執行個體化；2、4表示實體邏輯，需要執行個體化模型，将它們從概念具象化到某個特定的個體。
在根據領域模型得到了URI模闆後，就需要圍繞着URI進行API設計了。過程比較簡單，隻需構造這樣一張表格，表格中包含：角色、HTTP方法、URI、業務場景。
然後隻需填入角色、URI，然後按照窮舉法，填入所有的HTTP方法，比如對于/users/{uid}/subscriptions，可以有四行，分别對應GET\POST\PUT\DELETE。
下一步就是尋找業務方回報，幫助我們判斷這些由HTTP方法和URI組成的行為是否存在合理的業務場景。
比如經過讨論，認為/users/{uid}/subscriptions的PUT、DELETE不存在業務場景。
這個過程與角色=目标-實體法類似，其中業務場景是目标，實體則是通過URI表示的領域模型。是以這樣的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=".../chapter11.mp3" rel="voice">
<link href=".../chapter11.mp4" rel="video">
</article>
如果現在有三個用戶端，分别是閱讀器、聽書播放器、視訊播放器，那麼這些用戶端就可以根據超媒體拿到自己需要的服務資源而忽略其它資源。
通過使用超媒體，可以用同樣的API，支撐起完全不同的用戶端，通過超媒體描述的增強服務，讓用戶端與伺服器之間形成了一種協商與比對的關系，用戶端按需索取。
使用分布式超媒體設計API資源
超媒體有兩個構成要素，隻要具備這兩個要素，都可以看做超連結，比如html中的link：
- 指向關聯資源的連結（href）
- 與主資源的關聯關系（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架構的成敗，是以在構造資源的時候，也需要将緩存當做必須考慮的特性，詳加設計。
網際網路架構的精髓：
伺服器永遠不需要考慮用戶端的需求
，把用戶端的額外需求，當做漸進式服務消費的需求，隻需要提供對應的連結，剩下的就交給用戶端自行處理，通過将內建與訂制推向用戶端，進而保證服務端的穩定。
最後一步就是，将API作為模型的另一種表現形式，将其映射回所需支撐的業務流程之中，與業務方一起驗證這些API是否能夠滿足所有的需求。
參考資料
極客時間：如何落地業務模組化 徐昊