瞭解你的工具：九個問題
另有 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)
第 6 個模組，共 7 個，屬於 Data Architect 課程的第一章像資料架構師一樣思考。每個模組都可以單獨閱讀。 上一篇：為今天構建。為明天規劃。為失敗規劃。 · 下一篇：AI 時代的資料架構師
**本模組回答的問題：**如何評估任何一個工具，包括你從未見過的工具？
架構師需要判斷力。但沒有知識的判斷力用處不大。你仍然必須瞭解你的工具。
我教架構師很多年了，我用的一個框架，是一組關於你架構中每個重要工具或能力都應該能回答的問題。我最初教的是八個問題，後來加了第九個。技術在變，Salesforce 在變，新產品出現，老能力演進，而 AI 正在加速這一切。這些問題始終管用。
每當你學習或評估一項技術時，問一問：
- 它是什麼？
- 它用在哪裡？
- 我怎麼用它？
- 我有哪些替代方案？
- 它的優勢是什麼？
- 它的弱點是什麼？
- 我如何向開發人員、業務方和高管解釋它？
- 長期如何維護它？
- 它要花多少錢，需要什麼許可，有哪些限制？
如果你能回答全部九個問題，你就開始像架構師一樣理解這個工具了。注意清單上沒有什麼：「我能配置它嗎？」這很重要，但它只是瞭解工具的一部分。
1. 它是什麼？
Section titled “1. 它是什麼？ ”從顯而易見的問題開始，因為人們出人意料地常常跳過它。我們聽到一個產品或功能的名字，就立刻開始討論要不要用它。慢一點。它實際上做什麼？它是為解決什麼問題而設計的？它在架構中處於什麼位置，它不是什麼？架構師應該能在不復述營銷描述的情況下說清一項技術。如果我不能用幾句話解釋清楚某樣東西，我多半還沒有把它理解透。
2. 它用在哪裡？
Section titled “2. 它用在哪裡？ ”知道一樣東西做什麼，不等於知道它什麼時候屬於一個架構。它擅長哪類問題？什麼條件下適合用它，什麼條件下應該對它起疑？這是從「我瞭解這個功能」到「我能認出這個功能所解決的問題」的一步，而且是重要的一步。你不會想拿著自己最喜歡的技術四處找地方用。你要做的是認出問題，並知道哪些工具適合它們。
3. 我怎麼用它？
Section titled “3. 我怎麼用它？ ”是的，架構師應該理解實現。你不必構建每個元件，但你應該懂得足夠多，知道自己在請別人構建什麼。要知道它如何配置，開發人員如何使用它，資料如何進出，它如何部署和保護，以及執行起來是什麼樣子。我不希望架構師圍繞一項只在產品幻燈片上見過的技術做設計。親自動手：構建點東西，弄壞點東西，看看它實際上如何表現。架構紮根於現實才會更好。
4. 我有哪些替代方案？
Section titled “4. 我有哪些替代方案？ ”這可能是清單上最重要的問題。如果你只知道一種解決問題的方法，你面對的就不是架構決定，而是一個預設選項。每當有人提出一項技術，我都想知道我們還能怎麼做。另一項 Salesforce 能力？宣告式的還是程式碼？這項能力能否放在 Salesforce 之外？我們能否把資料留在原處而不是複製它，用一個事件而不是一次 API 呼叫，或者乾脆什麼都不構建？替代方案帶來權衡，而權衡是架構的核心。
5. 它的優勢是什麼？
Section titled “5. 它的優勢是什麼？ ”每個工具的存在都有原因。理解它真正擅長什麼：它讓什麼變得容易，在哪裡擴充套件得好，消除了什麼複雜度，優雅地解決了什麼問題。在技術的優勢與問題相吻合的地方使用它。這聽起來理所當然，但人們很容易因為已經擁有某個工具、團隊熟悉它、它是新的，或者有人看過一次演示就選擇它。這些可以是考慮因素，但它們不等於架構上的契合。
6. 它的弱點是什麼？
Section titled “6. 它的弱點是什麼？ ”這同樣重要。每項技術都有弱點，每一項都有。如果有人只能告訴你一項技術的優勢，你們就還沒在進行架構討論。它在哪些方面做得不好？複雜度在哪裡出現，規模變大時會怎樣？它帶來什麼運維負擔和依賴？哪些需求會把它推出最佳適用範圍？有弱點不總意味著我們不該用這項技術，而是意味著我們需要知道自己在接受什麼。你理解的權衡可以成為一個架構決定。你不理解的權衡可能會變成一個意外。
7. 我如何向不同受眾解釋它？
Section titled “7. 我如何向不同受眾解釋它？ ”這是把技術知識和架構技能區分開的問題之一。你能把同一項技術分別講給開發人員、業務方和高管聽嗎？這不應該是同一套解釋。開發人員需要的是 API、事務行為、安全、故障處理和實現模式。業務方關心的是它能帶來什麼，以及他們的流程會如何改變。高管關心的是成本、風險、時間、對組織的影響，以及這個決定會保留或關閉哪些選項。你不是在改變事實，而是在改變抽象的層次。如果你只能用一項技術文件裡的詞彙來解釋它，那就繼續加深你的理解。
8. 長期如何維護它？
Section titled “8. 長期如何維護它？ ”專案會結束。系統不會，至少我們希望不會。專案團隊離開後，總得有人擁有我們構建的東西。這意味著要知道它如何被監控、升級和排障，誰需要具備支援它的技能，變更如何部署和測試，以及當技術演進或 Salesforce 在底層改了什麼時會怎樣。想像一下三年後的樣子。我見過一些架構，上線那天非常巧妙，之後運維起來卻很痛苦。那不是成功。可維護性是架構的一部分。
9. 它要花多少錢，需要什麼許可，有哪些限制？
Section titled “9. 它要花多少錢，需要什麼許可，有哪些限制？ ”這是我在最初的八個問題之外加上的那個，今天我認為它不可能被省略。如果經濟上行不通，一項技術可以是完美的技術方案，卻仍然是錯誤的架構方案。它包含在我們已有的許可裡，還是一個附加項？它是按使用者、用量、消耗、儲存還是事務授權？隨著規模擴大，成本會怎樣？
然後是限制，每個平台都有：API、儲存、查詢、事務、併發、吞吐量和許可方面的限制。有些是硬限制，有些是軟限制；有些可以提高，有些不能；有些在我們的規模下無關緊要，直到我們再加一個零。你不必記住每一項 Salesforce 限制，那樣做是對時間的極大浪費。你需要知道限制是存在的，哪些對你的架構重要，以及什麼時候該去核實當前的數字。數字會變，架構問題依然存在。
一個執行個體：Apex 共用
Section titled “一個執行個體：Apex 共用 ”這是我最常用來說明這些問題如何發揮作用的例子之一。我們收到一項複雜共用的需求，任何基於所有者或基於條件的共用規則都滿足不了。這就把我們引向了 Apex 共用：由程式碼自己寫入共用記錄。於是現在我們需要知道 Apex 共用是什麼、用在哪裡、怎麼用，等等。這是一種升級：當我們需要的規則超出了基於所有者和基於條件的共用所能表達的範圍時，Apex 共用就是那個替代方案（問題 4）。
再看它的弱點（問題 6）。假設我們有一個擁有 1,000 萬或 2,000 萬成員的客戶社群，用的是 Customer Community 許可，而不是 Customer Community Plus。這些是大批次使用者。他們沒有角色，也完全不使用共用模型：他們的存取權限來自共用集和共用群組，通過他們的客戶和連絡人來比對。沒有可供 Apex 為他們寫入的共用記錄，所以 Apex 共用對他們不起作用。而把我們帶到這一步的，正是成本和許可這個問題（問題 9）：許可的選擇決定了到底有哪些共用工具可用。
所以，正如 Apex 共用是基於所有者和基於條件的規則的替代方案，你也可能遇到需要 Apex 共用的替代方案的情況。而到了那一步，複雜共用規則真的已經沒有基於配置的選項了。最後你只能把物件設為只讀，通過 Apex 來控制存取。這就是為什麼要在做選擇之前，而不是之後，問完全部九個問題。
不要死記平台
Section titled “不要死記平台 ”在你學習 Salesforce 架構時，這一點最為重要。不要試圖把 Salesforce 背下來。你做不到：平台太大，變化太快。我和 Salesforce 打交道很久了，仍然在學習。這很正常。
我希望你培養的是一個學習的框架。當 Salesforce 明天釋出一項新能力時，我不需要以前見過它。我知道該問什麼：它是什麼，它適合放在哪裡，我怎麼用它，還有什麼可以用，它擅長什麼，它在哪裡吃力，我如何解釋它，我如何運維它，它要花多少錢，限制在哪裡？現在我就可以開始評估它了。這比再背一張功能對照表有價值得多。
**考試之外：AI 讓九個問題更快得到回答，也更容易答錯。**遇到一項你不瞭解的技術，你可以讓 AI 解釋它、比較三種做法、列出它的限制和常見故障模式，或者反駁使用它的理由。這是一個了不起的研究助手。但它可能出錯、過時，或者自信滿滿地把兩個名字相近的產品或版本搞混。對於任何影響決定的事情，都要核實：追溯來源，檢視當前的文件、限制和許可。信任，但要驗證（模組 7）。
學習問題，而不只是答案
Section titled “學習問題，而不只是答案 ”在這門課裡我們會遇到很多技術。我不希望你收集答案，我希望你練習這些問題。當我們談到大物件、外部資料、Data 360、整合模式，或者 Salesforce 在本章寫成六個月後釋出的某項 AI 能力時，都問同樣的九個問題。
答案會變。**問題是持久的。**正是這一點，讓它成為一個架構框架，而不是一份學習指南。
瞭解你的工具：它們擅長什麼，不擅長什麼，還有什麼可以用，要花多少錢，在哪裡會出問題。還要懂得足夠多，能向那些必須與這個決定共處的人解釋它。這就是架構師學習技術的方式。
架構師在這裡決定什麼
Section titled “架構師在這裡決定什麼 ”- 一個工具是否適合這個問題，要用全部九個問題來評判，而不只看它能不能配置。
- 有哪些替代方案，以及這個工具的成本、許可和限制在你的規模下意味著什麼。
- 三年後誰來維護它，怎麼維護。
- 在依賴關於這個工具的哪些事實之前，要先核實它們。
- About High-Volume Community or Site Users (opens in a new tab)，Salesforce Help（英文，查閱日期 2026-10-09；再次查閱 2026-10-12）：大批次使用者（External Apps、Customer Community、High Volume Customer Portal 和 Authenticated Website 許可）沒有角色；他們的存取權限來自共用集和共用群組；他們不能被納入基於所有者的共用規則，他們擁有的記錄也不能手動共用。
- Platform Sharing Architecture (opens in a new tab)，Salesforce Architects（英文，查閱日期 2026-10-09；再次查閱 2026-10-12）：大批次使用者（Customer Community、High Volume Customer Portal、Authenticated Website）不使用共用模型，因為他們的許可不支援角色；存取是通過把使用者與客戶和連絡人查閱欄位相比對來實現的，藉助共用集或共用群組。同一頁面還列出了何時適合使用 Apex 託管共用。
- Account Sharing Sets for High Volume Customer Portal Users (opens in a new tab)，Trailblazer Community 提問，2024 年 11 月（英文，查閱日期 2026-10-09；再次查閱 2026-10-12）：一位從業者報告，為大批次使用者插入共用記錄時報錯失敗。這是一線經驗報告，不是官方文件。（線上 Trailblazer Community 將於 2026 年 10 月 30 日變為只讀，連結可能會變。）
- Create a Sharing Set for Experience Cloud Site Users (opens in a new tab)，Salesforce Help（英文，查閱日期 2026-10-09）：共用集授予使用者存取與其客戶或連絡人相關的記錄的權限。