可逆性測試
另有 28 種語言版本
English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)
第 3 個模組，共 7 個，屬於 Data Architect 課程的第一章像資料架構師一樣思考。每個模組都可以單獨閱讀。 上一篇：資料模型是骨架 · 下一篇：架構是權衡的藝術
**本模組回答的問題：**如何區分架構決定和普通決定？
架構師要做很多決定。
但並不是每個決定都是架構決定。
這個區分很重要。如果把每個決定都當成架構，我們就會把所有時間花在爭論那些相對容易改變的事情上。如果認不出真正屬於架構的決定，我們今天花五分鐘做的決定，可能要用五年才能解開。
那麼，怎麼區分呢？
我喜歡問一個簡單的問題：
這個決定以後要逆轉會有多難？
我把它叫作可逆性測試。
一件事越難逆轉，依賴它的東西越多，它就越值得架構上的關注。
有些決定改起來很便宜
Section titled “有些決定改起來很便宜 ”先從簡單的開始。
我們把一個欄位叫作 Customer Category（客戶類別）。六個月後，業務方認定大家其實都叫它 Customer Segment（客戶細分）。我們改了標籤。也許要更新一些文件，做一點使用者培訓，但這不是什麼重大的架構事件。不過，我們得繼續忍受原來的 API 名稱，因為改它的後果要大得多。所以這可能只是要應付一次標籤改動，以及隨之而來的混亂。
我們做了一個決定。我們改了主意。我們繼續往前走。
現在拿它和另一個決定比一比。
我們在為客戶建立一個識別符號。我們決定它的含義、它的格式，以及由哪個系統生成它。然後我們釋出了它。
Salesforce 用它。資料倉儲用它。整合平台用它。客戶入口網站用它。另外五個應用開始儲存它。報表和資料管道用它。也許最後客戶也會看到它。
三年後，有人說：
當初也許不該這樣設計這個識別符號。
這就是一場完全不同的對話了。
區別不在於一個決定比另一個更技術化。
區別在於可逆性。
事情可能是這樣發生的。假設業務一直用客戶名稱的一部分加一個數字來生成鍵。這種做法用了好幾年都沒問題，因為從來沒人需要改名。然後，一年或更久以後，真的有人改了名，突然之間，這些鍵就不符合其他資料所預期的模式了。這正是鍵不應該帶有任何內在含義的原因之一。
架構會產生引力
Section titled “架構會產生引力 ”一個架構決定往往會在周圍聚集越來越多的東西。我把它看作引力。
選定一個物件模型，自動化就會圍繞它構建起來。
選定一個鍵，其他系統就開始儲存它。
選定主資料放在哪裡，整合就開始朝它流入、從它流出。
選定一個共用模型，業務流程就開始依賴誰能看到什麼。
選定一種整合模式，各個系統就開始依賴它的時序和行為。
這些決定存在得越久，產生的引力就越大。最終，要改變最初的決定，就意味著要改變聚集在它周圍的一切。
AI 也會感受到這種引力。AI 工具從系統裡已有的東西出發：一旦某個關鍵設計元素進入系統，之後的每一次 AI 互動都會把它當作事實，在它之上繼續構建，構建，再構建。這個決定會在後續的許多決定中不斷迴響，而再也沒有人回頭重新審視最初的那個決定。每生成一次，引力就增加一分。
這就是「資料模型是骨架」之所以重要的原因。我們小心，不是因為變化不好。我們小心，是因為依賴讓變化變得昂貴。
問兩個問題
Section titled “問兩個問題 ”審視一個設計決定時，我會問兩個問題：
這有多難逆轉？
會有多少東西依賴它？
這兩個問題相關，但並不相同。有些東西技術上很容易改，卻有成百上千個使用方。以前人們常為了清晰而給標準物件改標籤，比如把客戶（Account）改成「Customer」。做起來很容易。後來另一個系統想用客戶來表示合作夥伴，就做不到了。另一些東西也許只有少數幾個使用方，卻需要一次龐大的遷移才能改動，比如一個在內部很多地方被引用的物件的 API 名稱。外面沒人看得到，但一個錯誤的名稱會一直讓團隊困惑。兩種情況都值得關注。
想想一些常見的資料決定：
- 哪個 Salesforce 物件來表示這個業務概念？
- 唯一識別符號是什麼？
- 哪個系統是記錄系統？
- 這些資料是複製到 Salesforce 裡，還是在別處存取？
- 這是一個物件，還是幾個相關的物件？
- 誰擁有這些資料，我們要保留多久？
- 我們預設的存取邊界是什麼？
- 這些資料如何在系統之間流動？
這些和決定某個欄位出現在 Lightning 頁面的什麼位置截然不同。頁面設計也很重要，但出錯的代價不同。
想想爆炸半徑
Section titled “想想爆炸半徑 ”思考可逆性的另一種方式是爆炸半徑：如果我改變這個決定，還有什麼會跟著動？
假設我們原本建模成欄位的東西，其實需要變成一個子物件。這不只是一次結構變更。現有資料怎麼辦？報表、期待那個欄位的整合、引用它的 Apex 和 Flow、安全、分析，還有行為依賴原始結構的 AI 代理程式，又怎麼辦？
半徑越大，最初的決定就越應該謹慎。
這也是為什麼架構師必須看到自己負責的那部分系統之外。從 Salesforce 內部看，某個改動也許很容易。從整個企業看，它可能影響另外十二個系統。
企業層面的決定和 Salesforce 層面的決定
Section titled “企業層面的決定和 Salesforce 層面的決定 ”資料架構師在兩個層面上思考。
**在 Salesforce 內部，**我們決定物件、關係、鍵、資料量、存取、自動化，以及資料在平台上的表現。
**在整個企業中，**我們問更寬泛的問題。客戶（Customer）到底在哪裡？誰擁有產品？哪個系統建立訂單？我們的權威識別符號是什麼？哪些資訊在系統之間複製，哪些留在原地？
這兩個層面必須連起來。我見過一些 Salesforce 實施，內部模型本身完全說得通，卻和周圍的企業格格不入。這還不夠。Salesforce 的結構需要在企業層面得到體現，企業層面的決定也需要回流到 Salesforce。
架構是雙向交通。
讓代價高的決定慢下來
Section titled “讓代價高的決定慢下來 ”技術領域的一個危險是：最容易實現的決定，看起來也像是最容易做的決定。它們不是一回事。
再建一個自訂物件很容易。再建一個欄位很容易。再接一個 API 越來越容易，而 AI 讓這一切變得更容易。
但實現的難易程度，幾乎完全說明不了架構決定的代價。
在做一個難以逆轉的決定之前，放慢腳步，足夠問一問：我們真正在解決什麼問題？我們考慮過哪些替代方案？我們在假設什麼？資料量增長時、業務變化時會發生什麼？還有什麼會依賴它？如果我們錯了會怎樣？
我們不需要每建一個物件都評審六個月。但我們確實需要與出錯代價相稱的思考。如果是給單個部門或子系統用的物件，可以快一點。如果是參考資料、關鍵的客戶物件，或者跨系統使用的東西，就花時間把它想透。
把原因寫下來
Section titled “把原因寫下來 ”重要的決定還有一個問題：人們會忘記當初為什麼這樣做。
三年後，有人看著一個架構問：「誰會這樣設計？」有時答案是，這確實是個糟糕的設計。這種事會發生。但有時當初有很好的理由：一個現在已經不存在的平台限制，一項監管要求，另一個無法支援首選方案的系統，或者為了趕上截止日期而有意接受的一個權衡。
如果我們只記錄決定了什麼，而不記錄為什麼，下一位架構師就無從知曉。
對重大的決定，把它寫下來。不需要 50 頁的文件。一份有用的決策記錄可以非常小：
**背景：**我們在解決什麼問題？
**選項：**我們考慮過哪些現實可行的替代方案？
**決定：**我們選了什麼？
**後果：**我們得到什麼，又放棄了什麼？
**負責人：**誰對這個決定負責？
**複審：**出現什麼原因或到了什麼日期，我們應該重新審視它？
價值不在文件本身。價值在於儲存推理過程。
當一個決定改變時，不要抹掉原來的那個，而是取代它。2027 年正確的決定，到 2030 年可能就不對了，因為資料量、業務、Salesforce 和我們的理解都在變。我想保留的是來龍去脈：當時的背景是這樣，決定是這樣以及為什麼，後來什麼變了，現在我們決定什麼。這比假裝我們一直都知道答案有價值得多。
考試之外：AI 縮短了從決定到依賴的時間。AI 工具可以在幾秒內提出一個資料模型，然後在其之上建立物件、自動化、整合程式碼和使用者介面。過去，一個有問題的決定要經過幾個月的開發，才會有很多東西依賴它；現在，依賴幾乎立刻就來了。所以，要評審產出背後的決定，而不只是產出本身。AI 可以幫忙：它能列出選項、質疑假設、起草決策記錄。但決定仍然由架構師來做，而且決定越難逆轉，人的判斷就越重要。
知道哪些決定重要
Section titled “知道哪些決定重要 ”我希望你培養的技能之一，是知道該把注意力花在哪裡。
不要把每一個配置選擇都變成一場架構峰會。
但也不要隨隨便便做出一個組織要揹負十年的決定。
問一問：
這以後要逆轉會有多難？
會有多少東西依賴它？
如果答案是非常難和很多，你多半就找到了一個架構決定。
放慢腳步。理解需求。探索替代方案。讓權衡看得見。做出決定。再把原因寫下來。
架構的目標不是做出永遠不會改變的決定。
目標是認出那些改主意會代價高昂的決定。
架構師在這裡決定什麼
Section titled “架構師在這裡決定什麼 ”- 哪些決定屬於架構：難以逆轉，且有大量東西依賴它們。
- 每個決定得到多少關注，與出錯的代價相稱。
- 哪些決定要寫下來，連同其背景、選項、後果、負責人和複審時點。
- Salesforce 層面的決定如何與企業層面的決定對齊。
- Object Relationships Overview (opens in a new tab)，Salesforce Help（英文，查閱日期 2026-10-09；再次查閱 2026-10-12）：在主要-詳細資料關係中，從記錄的存取權限和所有權跟隨主記錄，刪除主記錄會刪除其從記錄。
- Considerations for Object Relationships (opens in a new tab)，Salesforce Help（英文，查閱日期 2026-10-09；再次查閱 2026-10-12）：只有當每條記錄的查閱欄位都有值時，查閱關係才能轉換為主要-詳細資料關係；轉換會改變共用模型（變為 Controlled by Parent，由父級控制），而關係類型決定了可用的標準報表類型。
- Roll-Up Summary Field (opens in a new tab)，Salesforce Help（英文，查閱日期 2026-10-09；再次查閱 2026-10-12）：彙總摘要欄位只存在於主要-詳細資料關係上，並且必須先刪除，主要-詳細資料關係才能改為查閱關係。