像架构师一样思考
另有 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 个模块，共 7 个，属于 Data Architect 课程的第一章像数据架构师一样思考。每个模块都可以单独阅读。 上一篇：本章概览 · 下一篇：数据模型是骨架
**本模块回答的问题：**构建和做架构有什么区别？架构师到底做什么？
在我职业生涯的大部分时间里，我都是一个构建者。
我从开发人员起步。在转向 Salesforce 之前，我用 Java 和 .NET 工作，这些年来我一直在设计系统、写代码、集成平台、教架构师、评审架构。
但我一路上学到的最重要的一课是：做一个出色的构建者和做一个出色的架构师，并不总是同一回事。
构建者会问：
我该怎么构建它？
架构师则必须问另一组问题：
我们该不该构建它？
我们为什么要这样构建？
还有哪些替代方案？
当它变大时会发生什么？
当它出故障时会发生什么？
我们今天做的哪个决定，会让我们三年后后悔当初没有多想想？
我记得参与过一个零售企业的项目，业务里有预约。我问：每家门店每天有多少预约？接着问：你们有多少家门店？每周营业几天？我很快意识到，光是第一年我们就会有几百万条预约。这些就是架构师在项目开始时要问的问题。
这种思维上的转变，才是这门课真正要讲的东西。
手握蓝图的人
Section titled “手握蓝图的人 ”我在教架构师时用过很多次这个类比。
想象一个建筑工地。有人在浇混凝土，有人在布电线、装水管、搭墙架，还有几十种其他专门的工作。他们都必须非常擅长自己的活儿。
但也得有人手握蓝图。
这个人需要理解所有这些部分如何组合在一起。他们需要发现，项目某一部分正在发生的事情，什么时候会在别处造成问题。
这就是架构。
在技术领域，我们有时会误以为架构师就是懂得最多的那个人。其实不是这样。了解平台很重要，你需要技术深度。但架构不是知识竞赛。
架构师的工作是：做出好的决定（有时是在信息不完整、需求相互冲突的情况下），并理解这些决定的后果。
这是一种完全不同的技能。
不要照单全收需求
Section titled “不要照单全收需求 ”我希望架构师最先养成的习惯之一很简单：
多问为什么。
有人告诉你：
我们需要再加一个对象。
为什么？
我们需要把这个字段复制到客户上。
为什么？
我们需要把所有这些数据都存到 Salesforce 里。
为什么？
这不是故意刁难，而是要理解真正的业务需求，而不是立刻去实现别人提出的解决方案。
需求常常伪装成设计出现。
“我们需要一个新的自定义对象”不一定是需求。真正的需求可能是“我们需要单独跟踪这些信息”。这两者不是一回事。
一旦理解了真正的需求，你就可以开始探索替代方案。也许新对象正是正确答案。也许这些信息属于某个已经存在的地方。也许 Salesforce 根本就不该拥有这些数据。
架构师必须把业务需要什么和一种提议的实现方式区分开。
我们当时在做一个销售应用，客户有多级审批，每级都有一个审批人和一个日期。他们最初的要求是在业务机会上加审批人 2 和审批人 3 字段，各带一个日期。深入了解之后，我们发现审批可能不止两三级。于是我们把审批移到了一个子对象里。请求是加更多字段；需求是跟踪每一次审批，不管最后有多少次。
超越需求去思考
Section titled “超越需求去思考 ”多问为什么会带出两个习惯，本章后面各有一个模块专门讲。
答案通常不止一个。Salesforce 给了我们很多解决问题的方法，其中有些几乎马上就能看出是错的。在行得通的方法之间做选择，就是权衡的艺术（模块 4）。
而别人交给你的需求，并不是你的全部需求。没有人会说“确保夜间加载只成功一半时也能正常工作”，但这仍然是一项需求。我用三个视角审视每个设计：为今天构建，为明天规划，为失败规划（模块 5）。
想想请建筑师设计一栋楼的人。他们不会要求装火灾报警器或喷淋系统，也不会要求楼在地震中不倒。他们默认这是工作的一部分，无需开口。我们的世界也是一样。没有人会要求优雅的错误处理、日志，或者出故障时的恢复手段。哪些系统应该放进设计里，并把它们放进去，这是架构师的事。
让你的推理看得见
Section titled “让你的推理看得见 ”架构师不应该只是走进会议室宣布：“我们就这么做。”
你的工作还包括解释为什么。我希望利益相关方理解我们考虑过的替代方案和其中的权衡。这不是说要给高管一份 40 页的设计文档，而是能把同一个架构分别讲给开发人员、业务方和高管听：围绕同一个决定的不同对话。
做到这一点的方法，是清晰的蓝图和说明，就像建筑工地上手握蓝图的人。对数据架构师来说，最重要的蓝图之一就是数据模型。
如果没有人明白一个决定为什么这样做，那么很可能迟早会有人把它推翻。而且他们这样做可能有完全合理的理由，因为从来没有人解释过最初的决定。
架构师不需要亲手构建一切
Section titled “架构师不需要亲手构建一切 ”还有一个转变可能很难，尤其是对那些从开发转向架构的人来说。
你不必亲手构建所有东西。
我仍然喜欢在非常技术的层面理解事物是怎么运作的，这个基础很重要。但作为架构师，你的责任会大于你自己的实现。你不必亲手构建一切；你需要知道如何给真正做构建的人正确的方向和正确的参数。这意味着你要懂得足够多，才能指导他们的工作，才能识别出某个提议的实现什么时候会造成架构问题，才能在细节和全局之间来回切换。
有时这意味着深入研究一个查询、一个 API 或一个数据模型。
有时则意味着退后一步，问一问我们到底该不该做这些事。
而且，做构建的越来越不只是人。有了 AI，架构师可能直接和生成对象、代码和界面的工具一起工作。这时，方向、参数和准则是交给 AI 的，而把它们给好，也越来越成为架构师的责任。我们会在模块 7再回到这一点。
这是从构建者到架构师之路的一部分。
你的工作是做决定
Section titled “你的工作是做决定 ”归根结底，架构就是关于决定。
有些决定很容易改，有些则不然。
页面布局可以改，标签可以重命名。
但如果选错了基础数据模型，发布了几十个系统开始依赖的标识符，或者把关键数据的主副本放错了地方，那么改主意的代价就会高得多。
这些都是架构决定。而这门课集中讨论的，正是这类决定。
作为数据架构师，你要决定信息如何组织、放在哪里、如何增长、如何流动、谁能访问，以及企业的其他部分如何理解它。
技术很重要。
但了解每一个 Salesforce 功能并不是目标。
目标是培养判断力，知道该用哪个工具、什么时候用、你放弃了什么，以及接下来会发生什么。
这就是像架构师一样思考。
现在，我们可以开始像数据架构师一样思考了。
架构师在这里决定什么
Section titled “架构师在这里决定什么 ”- 一个请求是真正的需求，还是针对需求提出的一种设计。
- 在构建任何东西之前要问哪些问题：该不该做，为什么这样做，还能怎么做，当它增长或出故障时会发生什么。
- 哪些决定由架构师来做，哪些属于做构建的人；以及要给构建者（无论是人还是 AI）什么样的方向和参数。
- 如何解释一个决定，让开发人员、业务方和高管都能理解。