# Ch 05. 界定 API 邊界

根據 ADDR，**對齊**後的下一步是**定義**，所以這章主要是講產生活動步驟的部分

## 避免 API 的反模式

邊界或範圍清楚的 API 會讓使用者知道該選用哪支 API，而邊界或範圍模糊的 API 則可能來自以下反模式 (Anti Pattern)

1. 超級多合一 API 反模式
一支包含超級多功能或是多支功能整合起來才能正常運作的都會讓開發者感到挫折，雖然完全相反，但最終的體驗是相同的，都會需要開發者花費大量時間去閱讀文件才能理解功能

2. 超載 API 反模式
如果組織下有多個產品，通常會希望可以由特定團隊去維護單一產品，但這個團隊有可能就變成全公司的開發速度瓶頸，因為所有需要該產品的服務都需要等該團隊開發完畢，且有可能各自團隊有需求都會提給那個團隊，長久下來，這個產品就會變成一個盤根錯節的恐怖產品

書上建議可以根據不同的 Scope 去拆分 API，ex. 在 Book Catalog API 裡面只放書籍與分類相關的資料，如果不需要那麼多資料的話，就可以不用去依賴那支 API，但如果有需要其他資料的話，就還是可以去拿那支 API

3. 零散小工具 API 反模式
書上說團隊可能有很多支小工具 API 去處理很多雜事，但因為沒有整理之類的，導致我們有太多支小工具 API

## 有界語境、子領域與 API

為 API 劃分範圍的目的是，在同一個範圍內的 API，可以用統一的詞彙來表達意義，降低團隊的溝通成本，也讓使用 API 的開發者可以快速了解詞彙的意義
如果 API 是先拆分過範圍才指定不同團隊進行開發的話，通常不太會造成團隊間開發時的衝突

:::warning
這段沒有提到他們 3 個的差異，但自己看完後可以總結為以上內容
:::

## 用事件風暴界定 API 邊界

> 自己觀察了一下書上圖的變化，大概就是進入到下一個聚合時，會產生 API 的邊界，在一個聚合要結束準備進入下一個 API 時也會產生下一個邊界

根據書上的範例來說，因為邊界是進入下一個聚合時才會找到，因此在進入下一個邊界之前，是可以達成書上說的同一個邊界內都可以用同樣的語言來敘述同一件事

:::danger
但因為書上的案例比較簡單，因此不太確定實務上能不能這樣跑
:::

## 用活動界定 API 邊界

> 自己觀察了一下書上圖的變化，大概就是根據活動，將步驟拆分開來，可能會變成一個步驟一個 API

## API 的命名與範圍

將已經劃分出範圍的 API 命名，可以用範圍、受眾、應用當作取名的方向。


:::info
~~但看不懂書上的根據語境的標準，為什麼結帳跟付款都可以分類到 Shopping 裡面
但 Order Create 只有結帳，而 Payment Process 只有付款~~
根據第六章的敘述，Shopping 應該是沒有結帳及付款，應該是這邊寫錯了

:::

###### tags: `Web API 設計原則：API與微服務傳遞價值之道` `Book`