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.非 REST 服務使用協議緩衝區、Thrift 或類似的介面定義語言 （IDL）。
1.4.1.3.介面定義工具附帶乙個生成器，用於將服務的定義轉換為客戶端和伺服器。
1.4.1.4.還可以生成文件，測試工具可以使用 IDL 生成存根資料和模擬資料。
1.5.保持與 API 更改的相容性。
1.5.1.向後相容。
1.5.1.1.向前相容的更改允許客戶端在呼叫舊版本的服務時使用新版本的 API
1.5.1.2.乙個正在執行 1用於 Web 服務的 API 版本 0，但可以使用 1 從使用者接收資料API 的版本 1 由客戶端呼叫，該版本向後相容。
1.5.2.向後相容。
1.5.2.1.向後相容更改：新版本的庫或服務不需要更改舊客戶端**。
1.5.2.2.如果以 1 為目標** 開發的 API 版本 0 正在使用 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.需要維護服務的舊主要版本，並且需要將修復的錯誤回發到以前的版本。
1.6.5.API 版本通常由 API 閘道器或服務網格管理。
1.6.5.1.管理版本的方法應該是務實的。
1.6.6.保持文件與 API 一起進行版本控制。
2.1.API 的持續時間少於永續性資料。
2.1.1.公升級客戶端和伺服器 API 後，工作就完成了。
2.2.隔離資料庫並使用顯式架構將使資料演變更易於管理。
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.使用架構
2.4.1.嚴格的預定義資料列和型別，以及它們演變的重量級過程，導致了流行的無模式資料管理的出現。
2.4.2.無架構並不意味著“無架構”（資料將不可用）。
2.4.3.不要在已模式化的資料中隱藏無模式資料。
2.4.3.1.隱藏無模式資料是“弄巧成拙”的，你會得到顯式模式的所有痛苦，卻一無所獲。
2.4.4.無架構資料具有隱式模式，可以在讀取時提供或推斷。
2.4.5.採用無模式方法會產生嚴重的資料完整性和複雜性問題。
2.4.6.面向強型別的架構方法可降低應用程式的模糊性，從而降低其複雜性。
2.4.7.定義明確的資料架構將使應用程式保持穩定，並使資料可用。
2.4.7.1.清晰的架構將允許您在編寫資料時檢查資料的合理性。
2.4.7.2.使用顯式架構分析資料通常更快。
2.4.7.3.架構還可以幫助您檢測不相容的更改。
2.4.8.資料有時被描述為“一次寫入，多次讀取”，使用架構可以使其更易於閱讀。
2.4.9.架構遷移是自動化的。
2.4.9.1.更改資料庫的架構是危險的。
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的轉變2.4.9.3.大多數遷移工具都支援回滾，這意味著可以撤消從遷移中所做的更改。
2.4.10.保持架構相容性。
2.4.10.1.寫入磁碟的資料與 API 存在相同的相容性問題。
2.4.10.2.更改資料捕獲 （CDC） 是一種基於事件的架構，可將插入、更新和刪除轉換為下游使用者的訊息。
2.4.10.3.必須保護資料倉儲管道和下游使用者免受架構更改的影響。
2.4.10.4.相容性檢查應盡早完成，最好在提交時檢查資料庫 DDL 語句。
2.4.10.5.獨立的資料產品（可能只是乙個資料庫檢視）允許團隊與資料的使用者保持相容，而無需凍結其內部資料庫架構