可逆性测试
另有 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）：汇总字段只存在于主从关系上，并且必须先删除，主从关系才能改为查找关系。