1. 可演進的API

1.1. 隨著需求的變化，你需要改變你的API，即代碼之間的共用介面

1.2. 改變API很容易，但很難做到正確

1.3. 保持API小巧

1.3.1. 小巧的API更易於理解和演進

1.3.2. 只添加即刻需要的API方法或欄位

1.3.3. 帶有許多欄位的API方法應該有合理的預設值

1.3.3.1. 開發人員可以只專註於和自己相關的欄位，因為它們會繼承其他欄位的預設值

1.3.3.2. 預設值可使大型API在感覺上很小巧

1.4. 公開定義良好的服務端API

1.4.1. 切記使用標準工具來定義服務端API

1.4.1.1. OpenAPI通常用於RESTful服務

1.4.1.2. non-REST服務則使用Protocol Buffers、Thrift或類似的介面定義語言(interface definition language，IDL)

1.4.1.3. 介面定義工具自帶代碼生成器，可以將服務的定義轉換為客戶端和服務端代碼

1.4.1.4. 文檔也可以被生成，測試工具可以使用IDL來生成stub數據和模擬數據

1.5. 保持API變更的相容性

1.5.1. 向前相容

1.5.1.1. 向前相容的變更允許客戶端在調用舊版的服務時使用新版的API

1.5.1.2. 一個正在運行1.0版API的網路服務，但可以接收來自使用1.1版API的客戶端的調用，這就是向前相容

1.5.2. 向後相容

1.5.2.1. 向後相容的變更：新版本的庫或服務不需要改變舊的客戶端代碼

1.5.2.2. 如果針對1.0版API開發的代碼在使用1.1版時能繼續編譯和運行，這種變更就被稱為向後相容

1.6. API版本化

1.6.1. 隨著API的不斷演進，你將需要決定如何處理多個版本的相容性

1.6.2. 完全向後相容和向前相容的變更意味著API的所有的歷史版本和未來版本都可以相互操作

1.6.3. 你會想變更你的API，使之與舊的客戶端不相容

1.6.3.1. 當客戶端代碼難以變更時，API的版本管理最有價值

1.6.4. 版本化你的API意味著你在做出改變時將引入一個新的版本

1.6.4.1. API版本化自有其代價

1.6.4.2. 舊的主版本服務需要被維護，修複的bug也需要回傳到以前的版本

1.6.5. API版本通常由API網關或服務網格來管理

1.6.5.1. 管理版本所採用的方法要務實

1.6.6. 將文檔與你的API一起保持版本化

2. 可持續的數據管理

2.1. API比持久化數據存續的時間更短

2.1.1. 一旦客戶端和服務端API都升級了，就意味著工作完成了

2.2. 隔離資料庫和使用明確的schema將使數據演進更易於管理

2.3. 資料庫隔離

2.3.1. 共用的資料庫很難演進，並且會導致喪失自主性

2.3.1.1. 圖

2.3.2. 擁有共用資料庫的應用程式可以發展到直接依賴對方的數據，應用程式應該作為它們所使用的底層數據的控制點

2.3.3. 隔離的資料庫只有一個讀取者和寫入者

2.3.3.1. 其他所有流量都通過遠程過程調用

2.3.3.2. 圖

2.3.4. 隔離資料庫為你提供了共用資料庫所不具備的靈活性和隔離性

2.4. 使用schema

2.4.1. 僵化的預定義數據列和類型，以及它們演進的重量級過程，會導致流行的無模式(schemaless)數據管理的出現

2.4.2. 無模式並不意味著“沒有模式”（數據將無法使用）

2.4.3. 不要將無模式的數據隱藏在已經模式化的數據中

2.4.3.1. 隱藏無模式的數據是“自取滅亡”，你獲得了顯式schema的所有痛苦，卻沒有任何收益

2.4.4. 無模式數據有一種隱含的模式，可以在讀取時被提供或推斷出來

2.4.5. 採用無模式的方法會產生明顯的數據完整性和複雜性問題

2.4.6. 強類型的面向schema的方法降低了應用程式的隱蔽性，因此也降低了其複雜性

2.4.7. 為你的數據定義明確的schema將使你的應用程式保持穩定，並使你的數據可用

2.4.7.1. 明確的schema會讓你在編寫數據時可以對其進行合理性檢查

2.4.7.2. 使用顯式schema解析數據通常會更快捷

2.4.7.3. 架構還可以幫助你檢測到前後不相容的變化

2.4.8. 數據有時被描述為“一次寫入，多次讀取”，使用schema可以使讀取更容易

2.4.9. schema自動化遷移

2.4.9.1. 改變一個資料庫的schema是危險的

2.4.9.2. 可以管理資料庫遷移的工具

2.4.9.2.1. Liquibase

2.4.9.2.2. Flyway

2.4.9.2.3. Alembic

2.4.9.2.4. GitHub的gh-ost

2.4.9.2.5. Percona的pt-online-schema-change

2.4.9.2.6. Skeema

2.4.9.2.7. Square的Shift

2.4.9.3. 大多數遷移工具都支持回滾，也就是可以撤銷遷移產生的變化

2.4.10. 保持schema的相容性

2.4.10.1. 寫入磁碟的數據也有和API一樣的相容性問題

2.4.10.2. 變更數據捕獲(change data capture，CDC)是一種基於事件的架構，將插入、更新和刪除操作轉換為下游使用者的消息

2.4.10.3. 數據倉庫管道和下游用戶必須受到保護，以免遭受schema變更帶來的不良影響

2.4.10.4. 相容性檢查應該儘早地進行，最好是在提交代碼時通過檢查資料庫DDL語句來進行

2.4.10.5. 獨立的數據產品，可能只是資料庫視圖，允許團隊與數據的消費者保持相容，而不必凍結其內部的資料庫schema