像資料架構師一樣思考
另有 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)
Data Architect 課程第 1 章的學習指南。請先閱讀七個模組；這一頁幫你檢查自己記住了什麼。
**關於本學習指南。**它只依據本課程自己的內容，以及 Salesforce 公開發布的考試指南中的目標清單編寫。它從不基於真實的考試題目，也不聲稱知道考試會考什麼。如果你參加過考試，請不要把考題發給我：認證協議禁止分享考題，而且死記答案本來就不是成為架構師的正確方式。
這一章的考試知識點較少，這是有意為之。它講的是架構師如何思考，沒有哪個考試目標專屬於它。但考試是由情景構成的：一個業務、一些數字、一個約束，以及幾個都可能成立的答案。本章的習慣，就是你閱讀這些情景的方式。所以下面的清單寫明每一點支撐的是哪個目標，而不是聲稱它會被直接考到。
邊學邊打勾。每一條都連結到講授它的地方。
像架構師一樣閱讀情景（支撐所有目標）
- 我能把真正的需求和它所附帶的設計區分開（「我們需要審批人 2 和審批人 3 欄位」與「我們需要追蹤每一次審批」）。（不要照單全收需求）
- 我會尋找沒人說出口的隱含需求：所有權、新鮮度、失敗、保留、存取。（尋找隱含的需求）
- 我會給它配上數字：每天的量、每年的量、考慮增長後的量，並能察覺多一個零何時會改變答案。（瞭解你的數字）
- 在幾個都成立的答案之間，我會對照題中給出的需求和約束，比較每個答案得到什麼、放棄什麼。（知道你放棄了什麼，約束會改變答案）
- 我把成本、許可和限制看作工具是否合適的一部分，而不是事後才想起的事。（九個問題）
資料模型（支撐 DM-1）
- 我能根據模型是否支撐業務、能否隨業務成長、效能是否過關來評判它。（支撐。成長。效能。）
- 我能識別出過於扁平（欄位 1、欄位 2、欄位 3）、過度規範化或建在錯誤標準物件上的模型。（過於扁平、過於複雜，或者乾脆錯了）
- 我知道為什麼挑選清單適合短小穩定的清單，而查閱關係適合不斷增長或來自整合的清單。（解決問題的方法有很多）
- 我知道帶有含義的鍵（比如包含名稱的一部分）會在含義改變時失效。（有些決定改起來很便宜）
修改已有的東西（支撐 DM-1 和 SDM-2）
- 我知道為什麼修改欄位類型，或把已有欄位設為必填，可能在日後造成破壞，以及為什麼在程式碼或 Flow 引用該欄位時平台會阻止類型修改。（改動骨架要小心）
- 我知道寧可新增，不要修改；寧可棄用，不要突襲這一模式，也知道 Field Usage 可以把欄位標記為棄用候選。（改動骨架要小心）
- 我知道可逆性測試背後的主要-詳細資料關係事實：從記錄的存取權限和所有權跟隨主記錄，刪除主記錄會刪除其從記錄，彙總摘要欄位需要主要-詳細資料關係，而只有當每條記錄都有值時，查閱關係才能轉換為主要-詳細資料關係。（可逆性測試，延伸探索）
許可與共用（支撐 SDM-1）
- 我知道大批次社群使用者（包括 Customer Community）沒有角色，也不使用共用模型，所以存取權限來自共用集和共用群組，Apex 共用無法覆蓋他們。（一個執行個體：Apex 共用）
失敗（支撐 MIG-1 和整合相關章節）
- 我知道「作業已完成」不等於資料是正確的，也知道對賬如何找出沒能到達的記錄。（部分成功仍然是你需要弄清楚的失敗）
考試是底線，不是天花板。下面這些是本章中架構師需要的習慣，不管有沒有考題問到它們。
- **總得有人手握藍圖。**架構是在資訊不完整的情況下做出好的決定，並知道其後果。
- **資料模型是骨架。**其他一切都建立在它之上。
- **可逆性測試：**這有多難逆轉，又會有多少東西依賴它？
- **架構會產生引力。**讓變化變得昂貴的是依賴，而不是變化本身。
- **想想爆炸半徑，**在 Salesforce 內部，也在整個企業中。架構是雙向交通。
- **把原因寫下來：**背景、選項、決定、後果、負責人、複審。取代它，不要抹掉它。
- **在什麼方面最好？**次優的決定可以是最優架構的一部分，只要你知道自己在這樣做。
- **心裡裝著最優的圖景，**這樣你才知道自己正朝哪個方向偏離它，以及為什麼。
- **Think Correct. Think Fast.**速度來自在那一刻之前已經完成的思考。
- **為今天構建。為明天規劃。為失敗規劃。**沒人給你數字時，就按 30% 的增長來算。
- 學習九個問題，而不只是答案。
- **AI 是火箭助推器。**生成不等於判斷，不可逆的依然不可逆，人工評審不是走過場。信任，但要驗證。
| 術語 | 一句話解釋 |
|---|---|
| 架構決定 | 難以逆轉、且有大量東西依賴它的決定 |
| 可逆性測試 | 這有多難逆轉，又會有多少東西依賴它？ |
| 引力 | 隨著時間推移聚集在一個決定周圍的依賴 |
| 爆炸半徑 | 一個決定改變時，其他所有跟著變動的東西 |
| 決策記錄 | 背景、選項、決定、後果、負責人和複審時點，保持簡短 |
| 權衡 | 一個選項得到什麼，以及為此放棄了什麼 |
| 隱含需求 | 業務方不開口也期望有的東西，比如載入失敗時能夠恢復 |
| Steve 的「零的個數」 | 資料量上多一個零，就可能改變整個架構 |
| 對賬 | 逐條比較本該發生的和實際發生的 |
| 棄用 | 把某樣東西標記為即將淘汰，然後有計劃地讓它退役，而不是原地修改它 |
| 大批次使用者 | 沒有角色、處於共用模型之外的社群使用者（許可中包括 Customer Community） |
| 結構蔓延 | 因為建立起來很便宜而不斷堆積的物件和欄位，直到模型變得沒人設計過 |
按課程風格編寫的簡短情景題。開啟答案之前，先想好你的答案。
1. 銷售團隊要求在商機上加審批人 2 和審批人 3 欄位，各帶一個日期。你會問什麼，又可能構建什麼？
問為什麼，以及審批可能有多少級。如果可能多於兩三級，需求就是追蹤每一次審批，而不是加欄位：一個子物件，每次審批一條記錄。重讀不要照單全收需求。
2. 有人想重新命名一個欄位的標籤，另一個人想修改五個系統都已經在儲存的客戶識別符號的格式。哪個更值得你關注，為什麼？
識別符號。標籤改起來很便宜。識別符號通不過可逆性測試：難以逆轉，而且已經有大量東西依賴它。按照出錯的代價來分配注意力。重讀有些決定改起來很便宜。
3. 一個文字欄位已經用了好幾年。業務方現在想讓它存一個數字。你會怎麼做？
不要原地修改它。找出依賴它的東西（Flow、Apex、報表、整合、代理程式），以及舊資料會怎樣。通常的做法是：新加一個欄位，有計劃地遷移，再棄用舊欄位。重讀改動骨架要小心。
4. 1,200 個網點，每個網點每天 100 個預約，一年大約 305 天，每個預約兩條記錄，保留五年，每年增長 30%。大約有多少條記錄，為什麼這很重要？
第一年大約 7,300 萬條記錄（3,660 萬個預約，每個兩條記錄），考慮增長後五年超過 6.5 億條。同樣的功能，多了幾個零，就是截然不同的架構。重讀瞭解你的數字。
5. 一次夜間載入報告一百萬條記錄「已完成」。你怎麼知道它成功了？
對賬。接收方對儲存的每條記錄發出確認；傳送方把發出的和收到確認的進行比較。缺少確認就說明沒有成功，不管作業狀態怎麼說，而且它會告訴你哪些記錄需要重試、轉給人處理或發出告警。重讀部分成功仍然是你需要弄清楚的失敗。
6. 一個擁有 1,500 萬 Customer Community 使用者的社群需要複雜的記錄存取。有人提議用 Apex 共用。問題在哪裡？
他們是大批次使用者：沒有角色，處於共用模型之外，所以沒有可供 Apex 寫入的共用記錄。存取權限來自共用集和共用群組。是許可決定了有哪些共用工具可用。重讀一個執行個體：Apex 共用。
7. 一個 AI 工具在幾分鐘內為一個新應用生成了二十個物件。現在架構師的工作是什麼？
決定我們是否應該只有五個。把模型理解到足以為它辯護的程度：為什麼是這些物件和關係，鍵和主資料在哪裡，規模變大時會怎樣。核實它所依賴的事實。生成不等於判斷。重讀廉價的實現轉移了價值。
- Salesforce Certified Platform Data Architect Exam Guide (opens in a new tab)，Salesforce Help（英文，查閱日期 2026-09-25）：官方的考試目標清單及其權重。預約考試前，務必檢視最新版本。