API 優先的資料存取

一份資料一個擁有者 · 其餘走契約 · 路線圖項目 30

應用程式直接存取不屬於自己的資料庫。一個需要訂單的應用，開一條連線到訂單資料庫，對它的資料表下 SQL。這樣做行得通 —— 而這正是那些資料表什麼都改不了的原因。

取而代之的做法不是「多加幾個 API」，而是一條關於誰能寫什麼的規則，API 只是它的結果:每一份資料恰好有一個擁有者服務，其餘所有應用都走那個服務的契約。 一份資料的遷移，在直連授權被收回時才算完成 —— 不是在 API 發布時。

現在付的代價

每一項在下一頁都配一個具體場景展開。

	代價	一句話版本
01	schema 就是對外 API	不先找出所有讀方就改不了一個欄位名，所以最後就是不改。
02	授權的單位是資料表	一組憑證給的是一張表而不是一個操作，稽核軌跡記的是連線而不是呼叫方。
03	耦合是隱形的	沒有任何地方回答得了「這張表壞掉會影響誰」。
04	連線數隨實例數成長	每個副本各開自己的連線池直通資料庫 —— 而項目 26 正要讓副本數變成彈性的。
05	它擋住底下的平台	讀方不明，項目 06 就改不了複製架構，項目 27 也做不出站點獨立。

方向來自平台路線圖的項目 30;有日期的工作在應用程式現代化里程碑。