了解你的工具：九个问题
另有 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）：共享集授予用户访问与其客户或联系人相关的记录的权限。