像数据架构师一样思考
另有 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）：官方的考试目标清单及其权重。预约考试前，务必查看最新版本。