聆听名词
另有 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)
第 1 个模块，共 6 个，属于 Data Architect 课程第 2 章为含义建模数据。每个模块都可以单独阅读。 上一篇：本章概览 · 下一篇：画出关系
**本模块回答的问题：**如何在一次业务对话中找到数据模型的雏形？
和客户第一次通话时，我会做的一件事就是聆听名词。
我说的不是第一次设计会议，而是最初的那次对话，那时我还在努力理解这个业务以及他们想要达成什么。
他们在说，我在听。
我在留意这样的词：
零售合作伙伴。收货人。配送中心。装货清单。配送。路线。配送小组。卡车。
这些名词会立刻引起我的注意，因为在这段对话的某处，藏着我的数据模型的雏形。
我不会等到自认为完全理解了问题才开始。我在聆听的同时就开始看到数据：我听到名词，开始勾勒它们之间的关系，而这张草图又帮我构思下一次对话。有时，和客户的第一次会议结束时，我已经画好了一份只属于自己的数据模型。
对我来说，这一切从名词开始。
暂时忘掉 Salesforce
Section titled “暂时忘掉 Salesforce ”在这里，我希望你抵制一种本能，如果你做 Salesforce 管理员已经有一段时间，这种本能会特别强烈。
客户说客户，你想到的是：
客户（Account）。
他们说人，你想到的是：
联系人（Contact）。
他们说配送中心，你已经在琢磨是否需要一个自定义对象了。
先别这样做。
此时此刻，我不在乎一个客户最终会成为客户（Account）、个人客户、自定义对象还是别的什么。首先，我想理解业务。
这就是为业务建模和配置 Salesforce 的区别。如果我从 Salesforce 对象开始，我的思路就已经被限制在一种实现上了。我也许最后会落到预想的地方，但我希望是业务把我带到那里，而不是因为客户和联系人恰好是我最先认识的两个对象。
所以，在几分钟内，忘掉 Salesforce。去听真正经营这个业务的人如何描述他们的世界。
坐下、别动、建模
Section titled “坐下、别动、建模 ”在聆听一个业务之前，我们先来听听大家都已经懂的东西。我在现场授课时，会从狗讲起。
这是一只狗：Marcus 是 Bella 的主人。Bella 由 Maple Ridge Kennels 繁育。她是一只拉布拉多，会坐下、别动和握手。
聆听名词：Marcus、Bella、Maple Ridge Kennels、拉布拉多、坐下。不过这些都是名字，是具体的事物。我想要的是每个名字所属的那一类事物。Bella 是一只狗（Dog）。Marcus 是主人（Owner）。Maple Ridge Kennels 是繁育者（Breeder）。拉布拉多是一个品种（Breed）。坐下是一项技能（Trick）。五个名词，五个候选方框。
然后，我对每个名词都会问：**它是一个在做某项工作的人，还是一份数据？**Marcus 是一个人。但拥有 Bella 并不是一项工作；它是关于 Bella 的一个事实，而且迟早会有人问：“这只狗的主人是谁？”所以主人属于模型。教会 Bella 握手的训练师是一个在做某项工作的人，可能永远不需要一个方框，除非业务开始问是谁教会了哪项技能。
再注意候选这个词。品种真的是一个独立的方框，还是只是写在狗身上的一个词？先记住这个问题；我们会在模块 4做规范化时回答它。
这就是整个技巧，用在一个小东西上。现在我们来聆听一个真实的业务。
名词给你候选实体
Section titled “名词给你候选实体 ”我们来听听 Steve Trucking，这家家族企业我们会在整门课中使用。它把大件商品（冰箱、洗衣机、电视）从大型零售商的配送中心送到人们家里，其中一部分还负责安装。
在第一次对话中，我们听到：
- 零售合作伙伴（Retail Partner）
- 收货人（Recipient）
- 配送中心（Distribution Center）
- 装货清单（Manifest）
- 配送（Delivery）
- 路线（Route）
- 配送小组（Crew）
- 卡车（Truck）
这已经很有用了。我可以开始在白板上画方框了。
所以把名词放进矩形里。此时它们就只是这样：方框。没有连线，没有颜色，没有任何表示 Salesforce 的东西。课程后面，形状和颜色会开始有含义。现在，一个矩形只是业务谈论的一样东西。
然后开始给它们定位。放置每个方框时，你要想两件事：它们彼此如何关联，以及它们是哪类数据。有些是客户数据：我们打交道的企业和人。有些是交易数据，比如订单和订单项目：一再发生的事情。还有些是参考数据，比如一个企业提供的产品或服务：工作所依赖的东西。
在 Steve Trucking，零售合作伙伴和收货人是客户数据。装货清单、配送和路线是交易。配送中心、配送小组和卡车是工作所依赖的东西。
但这里有一个重要的词：候选。
名词是线索。它不会自动成为一个实体，更不会自动成为一个 Salesforce 对象。
在需求调研会上，我会把每个名词都记下来。他们说出的每个名词，我都会问自己一个问题：**这是一个在做某项工作的人，还是一份数据？**业务拓展经理是一个在做某项工作的人。那是一个用户、一个角色，也许是一个权限集。订单、发票、行项目：这些是数据。两者都重要，但它们在设计中会落到截然不同的地方，尽早把它们分开，可以让我免于给组织架构图上的每个职位都画一个方框。
那么，这些名词中有一些会是人。在 Steve Trucking，那就是等着冰箱的收货人、零售合作伙伴那边发送装货清单的人，以及配送小组：卡车上的司机和助手。这些是角色，而角色看起来也许不像数据。但当人对数据采取行动，或者与数据相关时，他们本身就需要在数据中得到体现。这是谁送的？谁签收的？谁发的装货清单？所以很多角色，有时是全部角色，最终也会进入模型。
听听 Steve Trucking 怎么说话，你会注意到一件事。他们从不只说“客户”。客户有两种。零售合作伙伴是 Steve Trucking 为之配送的大型零售商：它发送装货清单，并按每次配送付费。收货人是冰箱送达的那个人。收货人是从商店买的冰箱，可能从没听说过 Steve Trucking。
如果我只画了一个叫“客户”的方框，我就把两样完全不同的东西混在一起了。
也许配送中心足够重要，需要有自己的记录、历史、关系和属性。
也许另一个名词最后只不过是别的东西的一个属性。
这正是我们要去发现的。我们还没有在创建对象，我们在建立对业务的理解。
现在聆听关系
Section titled “现在聆听关系 ”名词给了我一个起点。然后我去听业务如何把它们联系起来。
一个零售合作伙伴运营着若干配送中心。
一个零售合作伙伴为每个配送中心的每个配送日发送一份装货清单。
一份装货清单列出若干配送。
一次配送送达一位收货人。
一条路线是一天的行程，包含大约十个停靠点。
一个两人配送小组驾驶一辆卡车。
现在，有些东西正在发生。我看到的不再是一串名词，而是开始看到一个模型。
问题也在这里开始出现。
一个零售合作伙伴可以有多个配送中心吗？
一次配送和一个停靠点是同一回事吗？
一个停靠点可以给两位收货人送货吗？
一个配送小组总是同样的两个人吗？
我们在意上个月哪个配送小组开的是哪辆卡车，还是只在意他们今天开的是哪辆？
注意我们在做什么。我们还没有在问 Salesforce 的问题，我们在问业务问题。而这些答案最终会驱动 Salesforce 的设计。
你的第一个模型不必完美
Section titled “你的第一个模型不必完美 ”我不指望自己最先画的方框能原封不动地保留下来。事实上，如果它们真的原封不动，我反而会起疑。
第一个模型的意义不在于正确，而在于给我们一个足够具体的东西，让我们发现自己哪里错了。
把配送、路线、配送小组和卡车放到白板上，大家就可以对它们作出反应。
“其实，一次配送不总是一件商品。它可能是一台洗衣机、一台烘干机，外加把旧的拉走。”
很好。再多说一点。
“我们不是把配送小组分配给一次配送，而是把配送小组分配给一条路线。”
太好了。路线上有什么？
“而且如果有安装，配送小组要等检查清单和照片都完成后才能关闭这个停靠点。”
现在我们学到了重要的东西。
一张图把一次模糊的对话变成了可以质疑的东西。这正是我喜欢尽早建模的原因之一。我不是要用一张漂亮的图让满屋子的人刮目相看，而是要学得更快。
模型是对话的一部分。
这就是你的概念模型
Section titled “这就是你的概念模型 ”我们开始构建的东西有一个正式的名字：概念数据模型。
在这个层次上，我感兴趣的是业务在意的重要事物，以及它们之间的关系。我还不担心标准对象和自定义对象、字段 API 名称、查找关系和主从关系、必填字段、索引、自动化、Apex 或 Flow。这些都很重要，我们会讲到。但如果在理解我们要建模的东西之前就决定它们，我们就是先去解决了错误的问题。
概念模型应该让会议室里不懂 Salesforce 的人也看得明白。这是一个有用的检验。如果在运营经理能看懂我的图之前，我得先解释 Delivery__c 是什么意思，那我就过早地进入实现了。
我希望他们看着模型说：
“对，我们的业务就是这样运作的。”
或者，更好的是：
“不对，不是这样运作的。”
因为这样我就有东西可以修正了。
没人说话时，同样的技巧也管用
Section titled “没人说话时，同样的技巧也管用 ”这不只是我在客户需求调研中使用的技巧。当“客户”是一份文档时，它同样管用。
当我研读一份需求文档时，我做的事情也大致相同。重要的业务概念是什么？描述了哪些关系？什么反复出现？什么有自己的生命周期、需要被单独识别，或者需要历史记录？什么在被创建、修改、分配、转移、排期或退役？
这些和我在第一次会议上留意的东西是一样的。在纸面上，这些线索把一段段需求变成一个我可以推理的模型，也变成下一次对话中更好的问题。
模型不只是你解决问题之后产出的东西。它是你用来解决问题的工具之一。
架构师在这里决定什么
Section titled “架构师在这里决定什么 ”第一轮结束时，我要决定的是：
- 哪些名词代表有意义的候选实体。
- 哪些不同的词代表同一个业务概念，又有哪一个词背后藏着两个概念（比如“客户”）。
- 哪些概念需要有自己的记录和生命周期。
- 主要概念之间如何相互关联。
- 在我能有把握地为它们建模之前，业务方需要回答哪些问题。
我现在还不决定 Salesforce 的实现。首先，我们需要把业务理解到足以把它画出来的程度。而一旦名词都上了白板，我接下来想理解的就是它们之间的连线。
考试之外：AI 改变了什么。把一份需求文档交给 AI 工具，它会在几秒内找出名词、提出实体、勾勒关系。用它来加速需求调研，但不要把理解外包出去：除非业务方告诉你，它无法知道“客户”在 Steve Trucking 意味着两种不同的东西。把它给出的第一个模型摆到经营这个业务的人面前，问一问：“你们的业务真的是这样运作的吗？”