---
schema_version: "1"
id: 52d218ccd2e13a8e4e0f366808f4eb925ce6303f2443cc9d00f751a73f4dc9a7
title: 意图
collection: architect
version: next
locale: zh-cn
portal_url: https://docs.salesforce.com/architect/next/zh-cn/well-architected/guides/intentional.md
canonical_url: https://staging.architect.salesforce.com/docs/architect/zh-cn/well-architected/guide/intentional.html
source_site: staging.architect.salesforce.com
content_type: documentation
content_hash: ab03a3ea7d7c32279442ce061ea90be075a106b53d9375d539937082ad41c18a
products:
  - 精心设计
  - Architect Site Content Repo
updated_at: 2024-07-01T00:00:00Z
---
> 在[这里](/docs/architect/zh-cn/well-architected/guide/contributors)阅读我们的更新计划。

## 导言

意图性解决方案会随着时间的推移立即提供业务价值。意图架构以战略性的方式规划和交付，可以有效维护，并且易于人类阅读和理解。

功能和修复的优先级以对业务和技术利益相关者透明的方式提供。工程选择创建易于交付和维护团队使用的实施，无需添加功能或复杂化。意图性架构更容易拥有、维护和随业务发展，因为它们遵循明确一致的实施模式。生成器可以解释和实施新功能的设计，维护团队可以理解实施内容的文档。

您可以通过关注三个关键领域来创建更具针对性的系统：策略、可维护性和可读性。

## 策略

架构中的策略意味着系统经过深思熟虑的规划和交付。这意味着交付和维护团队清楚地了解今天和将来要完成的工作，每个人都围绕要完成的工作的“原因”保持一致。这意味着紧急请求可以有效分类，利益相关者可以清楚地了解请求的影响和权衡。

通过关注预先测试、路线图和治理，您可以将更清晰的策略构建到您的架构中。

### 优先级

优先级意味着计划您将交付的工作的顺序和范围。优先级包括了解交付品对业务的真正影响，根据其他工作请求和产品或计划的整体路线图评估这些影响。

评估给定工作项目影响的一种方式是查看业务的实际成本或收益。在您确定了自动化的 [KPI](/docs/architect/zh-cn/well-architected/guide/automated#kpi) 后，您可以使用[业务影响计算工作表](/docs/architect/zh-cn/resources/guide/kpi-spreadsheet-template)来评估实施的总体成本或收益。这些计算可以帮助您从利益相关者那里获得关于构建什么自动化以及以什么顺序构建的一致和支持。它们还可以帮助您确定要推迟或避免的自动化。有关识别有效工作的更多信息，请查看[流程设计](/docs/architect/zh-cn/well-architected/guide/automated#流程设计)。

为交付建立优先级框架也有助于您和您的维护团队管理用户期望，并与路线图保持一致。

可用于确定优先级的一些注意事项包括：

- 交付品的业务影响（成本/效益）
- 交付品所需的新工作量
- 维护交付件所需的工作量

以下[模式和反模式](/docs/architect/zh-cn/well-architected/guide/intentional#策略模式和反模式)列表显示了 Salesforce 工作时正确(和糟糕)的优先级。您可以使用这些来验证您的实施计划，或者在构建之前确定您需要更好地确定优先级的地方。

要了解有关 Salesforce 工具的更多信息，以帮助确定优先级，请参见[工具相关意图](/docs/architect/zh-cn/well-architected/guide/intentional#与意图相关的工具)。

### 路线图

路线图是确定优先级、经过验证、定义明确的待办事项视图。有效的路线图清楚地描述了未来工作的业务影响和技术影响。让业务和技术利益相关者参与进来是路线图的关键部分。路线图使您能够在任何工作开始前获得关于方法和结果的反馈和支持。归根结底，路线图让每个利益相关者了解未来工作的“原因”。

如果您的团队使用待办事项，重要的是要了解您的路线图不是待办事项中的汇总或项目列表。关系相反：只有当项目能够明确和可靠地与路线图上的交付品联系起来时，它们才会进入待办事项。通过利益相关者的参与创建的高质量路线图，使交付和维护团队能够清楚地看到他们应该关注什么以及如何确定请求的优先级，从而更容易理清冲突的请求和管理利益相关者的期望。

不良或不存在路线图会导致：

- 不清楚新特性和功能何时可用
- 利益相关者之间的优先事项冲突
- 交付的解决方案与整体组织愿景脱节
- 难以理解正在进行的工作
- 团队之间的工作负荷不均衡
- 对工作项目之间的关系和依赖性缺乏可见性
- 由于依赖关系管理不善，实施暂停

利益相关者通常需要与其角色相符的信息来做出决策。创建有效的路线图需要清楚地了解您的受众以及他们需要的信息类型。路线图分为两种风格，以支持业务和技术受众。每个样式包含两个级别的粒度，以支持不同类型的信息。

业务路线图帮助利益相关者规划组织变革，利用增长机会，并与公司目标保持一致。业务路线图还提供了一种方式来确保 IT 支出与整体业务愿景保持一致。

- 创建业务能力路线图，向主管利益相关者展示将启用的功能。这种类型的路线图包含有关功能本身以及如何与业务目标保持一致的高级详细信息，例如提高运营效率或推出新产品线。
- 创建业务功能路线图，以深入了解特定功能，并在您需要帮助业务利益相关者进行资源规划、预算编制和变更管理时显示支持特性和功能。

技术路线图帮助技术利益相关者进行预算和资源分配规划。它们还帮助实施团队了解他们的项目适合作为更大整体的一部分的位置，并确定任何跨团队的依赖关系。

- 创建技术系统路线图，以显示将实施的特定系统，以及任何系统级依赖性。这种类型的路线图显示了高级系统信息，以及系统和业务功能之间的协调。
- 创建技术组件路线图，深入了解将部署以帮助满足资源规划和支持要求的系统的特定组件。这种类型的路线图显示了组件级信息和实施要求（例如，声明性开发、专业代码等）。

请确保路线图包含现实的时间表。一个常见的错误是只包括实施系统所需的时间，而不考虑完成相关活动所需的时间。这会导致过度分配实施团队成员，并比预期的延迟更长。在创建路线图时，请考虑完成以下内容所需的时间：

- 所有新功能和更新功能的文档
- 维护支持新功能所需的现有功能
- 支持集成所需的相关系统的更新
- 上线后项目团队的支持率提高
- 测试、培训和变更管理

高度一致的业务和技术路线图传达了功能何时上线以及落后技术的整体视图。下面的[模式和反模式](/docs/architect/zh-cn/well-architected/guide/intentional#策略模式和反模式)列表显示了 Salesforce 组织的正确(和糟糕)路线图。您可以使用这些来验证或改进您的路线图策略。

要了解有关可以帮助您绘制路线图的 Salesforce 工具的更多信息，请参见[工具相关意图](/docs/architect/zh-cn/well-architected/guide/intentional#与意图相关的工具)。

### 治理

治理是您用来与利益相关者一起处理优先级、决策和变更管理的结构。治理明确了如何做出和传达决策。它为反馈和请求进入决策过程以及所有利益相关者了解维护和开发工作的状态提供了一致的方式。治理有助于发布清晰一致的管理流程，并帮助所有团队成员了解他们的角色和职责。

如果没有适当的治理，团队会遇到各种问题，包括：

- 对重叠特性和功能的请求是临时的
- 实施团队优先考虑“更容易”的努力或来自更具影响力的利益相关者的请求，而没有适当考虑业务价值、权衡或整体组织目标
- 缺乏一致的审批和审查流程
- 发布节奏和质量不一致
- 开发工作中的高缺陷率、覆盖、冲突和冗余工作

也许系统没有有效治理的最明显的迹象是发布缓慢和繁琐。认识到治理体系的规模不是衡量其有效性的标准非常重要。事实上，精心设计的治理系统（就像许多大型企业的系统一样）可以限制发布的速度和频率。

良好的治理是让糟糕的自定义很难通过早期开发阶段，让好的自定义可以预测和一致地投入生产。

治理工作往往具有反作用。当问题（例如过多的技术债务）开始成为业务问题时，就会启动或加倍它们。在许多情况下,不幸的回应是企业“锁定”开发工作和版本，而不是创建有效的[设计标准](/docs/architect/zh-cn/resources/guide/design-standards-template)和构建自动化来在开发人员工具链和源控制系统中强制执行这些标准。

在构建 Salesforce 治理系统的框架时，请包含以下元素，并考虑这些需要回答的关键问题：

- **工作请求。**用户如何询问功能或特性？如何报告错误？
- **优先级和工作规划。**谁决定什么工作请求重要？如何确定工作范围、确定优先级、接受或签署？
- **环境和发布计划。**开发、测试和发布的环境漏斗是什么？谁负责配置、刷新和提供访问权限？谁负责部署和验证？如何及何时发布更改？如何在 Salesforce 发布周期内处理部署或环境？（有关更多信息，请查看[应用程序生命周期管理](/docs/architect/zh-cn/well-architected/guide/resilient#应用程序生命周期管理)。）
- **服务所有权和生产支持。**谁支持什么？谁处理“热修复”生产问题？如何测试和发布这些项目？谁负责组织的整体安全标准？

以下[模式和反模式](/docs/architect/zh-cn/well-architected/guide/intentional#策略模式和反模式)列表显示了 Salesforce 组织的正确(和糟糕)治理。您可以使用这些来验证或改进您的治理策略。

要了解有关适用于治理的 Salesforce 工具的更多信息，请参见[工具相关意图](/docs/architect/zh-cn/well-architected/guide/intentional#与意图相关的工具)。

### 策略模式和反模式

下表显示了在您的组织中要查找（或构建）的模式的选择，以及要避免或针对补救的反模式。

✨ 在[模式和反模式探索](/docs/architect/zh-cn/well-architected-tools/guide/easy-strategy)器中，发现更多策略模式。

<table>
    <colgroup>
       <col span="1" style="width: 10%;">
       <col span="1" style="width: 45%;">
       <col span="1" style="width: 45%;">
    </colgroup>
    <tbody>
        <tr>
            <th scope="colgroup"></th>
            <th scope="colgroup">模式</th>
            <th scope="colgroup">反模式</th>
        </tr>
        <tr>
            <td rowspan="2"><b>优先级</b></td>
            <td><b>在您的文档中：</b>
            <br> - 所有新工作项目都有明确的业务价值度量（例如，收入增加、流程优化的成本节约等）
            <br> - 路线图显示基于业务价值的工作优先级</td>
            <td><b>在您的文档中：</b>
            <br> - 与工作关联的业务价值不明确或不存在
            <br> - 路线图不存在</td>
        </tr>
        <tr>
            <td><b>在贵公司内：</b>
            <br> - 已确定所有工作项目的实施和维护费用
            <br> - 根据业务影响、交付所需的新工作量和维护所需的工作量确定功能请求的优先级</td>
            <td><b>在贵公司内：</b>
            <br> - 实施和维护功能的相关成本不明确
            <br> - 请求以临时或先进先出的方式传递</td>
        </tr>
        <tr>
            <td rowspan="2"><b>路线图</b></td>
            <td><b>路线图：</b>
            <br> - 传达专为受众定制的信息（业务或技术）
            <br> - 以正确的详细程度传达信息
            <br> - 显示开始和结束日期
            <br> - 显示先决条件和依赖性</td>
            <td><b>路线图（如果存在）：</b>
            <br> - 用作项目启动材料，而非交付的工件
            <br> - 请勿帮助利益相关者和交付团队保持一致
            <br> - 混合详细信息级别（例如，通过在同一路线图中包含系统和组件）
            <br> - 包含并非针对受众定制的信息（例如，同一路线图中的业务功能和系统）</td>
        </tr>
        <tr>
            <td><b>在您的业务中：</b>
            <br> - 利益相关者了解工作项目的“原因”
            <br> - 交付团队知道如何根据长期优先级评估待办事项
            <br> - 团队知道谁在做什么以及如何管理依赖性
            <br> - 工作是有意的，即使优先级需要快速更改</td>
            <td><b>在您的业务中：</b>
            <br> - 工作从待办事项中提取，没有明确的“原因”
            <br> - 团队难以协调相互依赖的工作，并且经常在不知不觉中重复工作
            <br> - 工作往往是反应性的
            <br> - 利益相关者通常对正在做的事情感到沮丧和困惑，并且对何时交付新功能感到忌惮</td>
        </tr>
        <tr>
            <td><b>治理</b></td>
            <td><b>在您的业务中：</b>
            <br> - 用户可以轻松报告错误并请求功能
            <br> - 记录工作项目的优先级过程，并对所有利益攸关方透明
            <br> - 环境战略有明确的文档记录，开发环境与文档记录相匹配
            <br> - 发布计划可以预测，对所有交付团队成员透明
            <br> - 团队成员知道谁在整个应用程序生命周期中负责什么
            <br> - 用户和交付/维护团队清楚了解版本
            <br> - 生产支持流程清晰，热修复程序有清晰的生产路径
            <br> - 团队和项目仅使用为业务用途批准的 AI 模型</td>
            <td><b>在您的业务中：</b>
            <br> - 错误报表和功能请求是临时的
            <br> - 工作项目没有明确的优先级
            <br> - 环境是临时配置的，可能不会以可预测的方式刷新；开发人员通常没有他们需要的环境和访问权限
            <br> - 交付团队和用户无法预测发布
            <br> - 团队不知道谁负责什么
            <br> - 热修复是临时解决的
            <br> - 您的待办事项已成为过时和停滞的“意见库”
            <br> - 治理机构充当帮助台，对支持请求进行故障排除
            <br> - 文档不容易访问
            <br> - 团队会临时选择 AI 模型</td>
        </tr>
    </tbody>
</table>

## 可维护性

可维护性意味着系统可以保持健康状态，新功能进入系统，技术债务定期、可预测地移出系统。可维护的系统使您的团队能够以可预测的速度和质量为业务提供价值。系统的可维护性取决于几个因素，包括可读性、松耦合性以及测试策略的彻底性。

最重要的是，系统的可维护性取决于其设计的简单性。本节介绍如何创建更直接的解决方案设计，并提高可维护性。

您可以通过关注两个关键来构建更容易维护的解决方案：使用标准功能而不是自定义功能，以及处理技术债务。

### 标准与自定义功能

Salesforce 提供一系列预构建的解决方案 — Sales Cloud、Service Cloud 和许多 Salesforce 行业解决方案，以及创建您自己的自定义解决方案的灵活性。支持 Salesforce 自有云解决方案的基础服务也适用于构建于 Salesforce Customer 360 平台的任何自定义解决方案。将 Salesforce 的预构建服务和解决方案用作尽可能多的解决方案的可信基础。

使用预构建平台服务有两个明显的优势。首先，您的应用程序自然会受益于每个版本的最新 Salesforce 创新。其次，您的开发团队可以专注于扩展和深化您的 Salesforce 解决方案提供的业务功能，而不是处理基本的架构繁重的工作。

从架构的角度来看，正确选择何时使用标准功能以及何时构建自定义功能并不具有挑战性。密钥是：

- **自定义平台意味着修改和扩展，而不是复制。**当您设计或评估您的架构时，您应该问：这是否已经存在于 Salesforce 平台的某个地方？如果答案是“_是,但是...\[插入业务利益相关者想要的更改...]”_,那么在平台中使用预构建功能。要完成的架构工作是确定配置预构建 Salesforce 功能的最有用的方式，以满足业务预期。
- **没有自定义是小事**。随着时间的推移，每个变化都会产生影响。如果您需要实施自定义解决方案，您可以通过尽可能选择使用低代码技术并在实施中创建可[组成单元](/docs/architect/zh-cn/well-architected/guide/composable)来减轻系统不可避免的[技术债务](/docs/architect/zh-cn/well-architected/guide/intentional#技术债务)。
- **考虑构建-购买频谱**。[Salesforce AppExchange](https://appexchange.salesforce.com/)是扩展 Salesforce 的应用程序和解决方案市场。AppExchange 应用程序可以提供功能，而无需在构建和维护自定义解决方案时涉及的开销。评估 AppExchange 解决方案时，请考虑以下事项：
  - 确定解决方案功能和差距。理想情况下，您会找到满足所有业务需求的应用程序。实际上，您可能找不到完美匹配。在您评估解决方案时，将潜在解决方案中的功能映射到业务需求的优先级列表。这将帮助您找到最能满足您最关键要求的解决方案。
  - 使用 Sandbox 和免费试用。使用免费试用期来评估 Sandbox 环境中的应用程序，并确定最合适的应用程序。确定应用程序是否需要您进行与现有配置冲突的配置更改。
  - 考虑短期和长期成本。根据基于订阅的应用程序的经常性成本，评估长期应用程序维护的节省。避免出现以下情况：您必须为业务利益相关者永远不会使用的很多功能支付经常性费用。
- **使用 Salesforce 中的预构建数据模型。**Salesforce 为销售、服务和各种行业垂直行业提供预构建的数据模型。使用 Salesforce 提供的数据模型可确保系统中的功能仅被定义一次（消除冗余和孤岛），在整个系统中建立单一的真实来源，更容易使用分析来理解应用程序数据，更容易使用 Salesforce 的预构建人工智能服务，降低维护成本（通过减少您需要支持的自定义），并减少技术债务。

就这么简单。从下面的[模式和反模式](/docs/architect/zh-cn/well-architected/guide/intentional#可维护性模式和反模式)中可以看出,反模式可以归结为在自定义解决方案中复制标准功能，或者使用更复杂的技术来提供自定义。

在实践中，您可能会遇到这样的情况，即业务利益相关者将自定义功能反模式视为最佳或唯一可行的前进道路。在这些情况下，您必须向利益相关者解释选择这条道路所涉及的权衡，然后彻底记录决定、其理由和实施。在这一领域，尽早交付核心价值并随着时间的推移进行调整，可帮助利益相关者更好地了解最佳前进方向。

要了解有关 Salesforce 工具的更多信息，以帮助您提高可维护性，请参阅[工具相关意图](/docs/architect/zh-cn/well-architected/guide/intentional#与意图相关的工具)。

### 技术债务

技术债务是任何系统的自然组成部分。当技术或业务需求发生变化时，昨天的合理设计可能会成为反模式。也许，为了填补 Salesforce 平台功能中的空白而构建的东西会随着新的 Salesforce 版本或产品发布而突然变得多余。也许性能更好或更灵活的技术取代了您已经实施的技术。技术债务可以通过多种方式产生。

使用 Salesforce Customer 360 平台构建应用程序的一个关键好处是[平台内置向后兼容](/docs/architect/zh-cn/fundamentals/guide/architecture-basics#平台-api)性。这意味着新的平台创新可能会改变您未来应使用的解决方案的模式，但您基于以前的 Salesforce 技术构建的解决方案的日常功能将继续有效。随着时间的推移，任何基于旧技术的解决方案都会开始为您的应用程序添加新功能带来风险或瓶颈，并降低整体解决方案的运行状况。

规划和执行定期工作以解决技术债务问题对于在 Salesforce 解决方案中保持健康、简单的设计至关重要。不规划、审计和补救技术债务是创建架构不佳的系统的一种肯定方法。

最小化技术债务的一个方法是尽可能避免引入它,避免快捷方式,并优先使用[标准功能而不是自定义](/docs/architect/zh-cn/well-architected/guide/intentional#标准与自定义功能)功能。快捷方式，例如硬编码值，可能会节省时间，但从长远来看，它们会产生必须偿还的债务。

从架构角度解决技术债务问题的关键包括：

- 确定作为或不作为的实际[成本或收益](/docs/architect/zh-cn/resources/guide/kpi-spreadsheet-template)
- 正确[的路线图](/docs/architect/zh-cn/well-architected/guide/intentional#路线图)
- 构建可[组合解决方案](/docs/architect/zh-cn/well-architected/guide/composable)

困难可能是让利益相关者与采取行动保持一致。一些利益相关者可能会将日常维护视为解决“昨天的错误”或剥夺他们希望预算支持的功能。

显示作为和不作为的实际业务影响，以及明确界定的交付品和时间表，可以帮助您的利益相关者了解解决技术债务的价值和相对优先级。坚持不懈地开展工作，将技术债务与业务影响联系起来，不仅有助于您的利益相关者更好地理解要完成的工作。它还将帮助您确保以真正有利于用户的方式识别和解决技术债务。

以下[模式和反模式](/docs/architect/zh-cn/well-architected/guide/intentional#可维护性模式和反模式)列表显示了 Salesforce 组织正确(和糟糕)的技术债务管理。

要了解有关可帮您解决技术债务问题的 Salesforce 工具的更多信息，请参阅[工具相关意图](/docs/architect/zh-cn/well-architected/guide/intentional#与意图相关的工具)。

### 可维护性模式和反模式

下表显示了在您的组织中要查找（或构建）的模式的选择，以及要避免或针对补救的反模式。

✨ 在[模式和反模式探索](/docs/architect/zh-cn/well-architected-tools/guide/easy-maintainability)器中，发现更多可维护性模式。

<table>
    <colgroup>
       <col span="1" style="width: 10%;">
       <col span="1" style="width: 45%;">
       <col span="1" style="width: 45%;">
    </colgroup>
    <tbody>
        <tr>
            <th scope="colgroup"></th>
            <th scope="colgroup">模式</th>
            <th scope="colgroup">反模式</th>
        </tr>
        <tr>
            <td rowspan="5"><b>标准与自定义</b></td>
            <td><b>在设计标准中：</b>
            <br> - 有一个明确的指导原则来避免不必要的自定义解决方案
            <br> - 解决方案的指导原则使用以下优先级：1.使用内置平台服务，2.在构建自定义解决方案之前，请考虑 AppExchange 应用程序。在编写代码之前使用低代码自定义</td>
            <td><b>在设计标准中：</b>
            <br> - 设计标准要么不存在，要么没有明确的理由来避免不必要的自定义和代码</td>
        </tr>
        <tr>
            <td><b>在您的文档中：</b>
            <br> - 决策记录显示选择构建或购买解决方案时的短期和长期成本计算</td>
            <td><b>在您的文档中：</b>
            <br> - 决策记录在选择构建或购买解决方案时不考虑短期和长期成本</td>
        </tr>
        <tr>
            <td><b>在数据模型中：</b>
            <br> - 没有对象的名称或功能与标准对象重复
            <br> - 标准对象未用于超出预期范围的目的</td>
            <td><b>在数据模型中：</b>
            <br> - 对象与标准对象的名称和/或功能重复
            <br> - 标准对象用于远远超出预期范围的目的</td>
        </tr>
        <tr>
            <td><b>在LWC、Aura或Visualforce中:</b>
            <br> - 不存在覆盖标准页面视图机制的代码</td>
            <td><b>在LWC、Aura或Visualforce中:</b>
            <br> - 代码用于覆盖标准页面视图机制，通常以单页面应用程序的形式存在</td>
        </tr>
        <tr>
            <td><b>在LWC、Aura或Apex中:</b>
            <br> - 没有代码尝试覆盖或规避平台执行顺序</td>
            <td><b>在LWC、Aura或Apex中:</b>
            <br> - 代码尝试覆盖或规避平台执行顺序</td>
        </tr>
        <tr>
            <td rowspan="3"><b>技术债务</b></td>
            <td><b>在路线图中：</b>
            <br> - 计划解决技术债务问题
            <br> - 交付件和开始/结束日期明确</td>
            <td><b>在路线图中：</b>
            <br> - 没有计划解决技术债务问题的工作
            <br> - 交付品不明确；开始/结束日期不明确</td>
        </tr>
        <tr>
            <td><b>在您的决策记录中：</b>
            <br> - 技术前/技术后债务补救的 KPI 有明确记录
            <br> - 关于作为和不作为的权衡讨论侧重于业务成本或收益</td>
            <td><b>在您的决策记录中：</b>
            <br> - 技术债务补救没有可衡量的 KPI
            <br> - 从技术或 IT 角度考虑技术债务，与业务无关</td>
        </tr>
        <tr>
            <td><b>在您的组织中：</b>
            <br> - 没有不支持的或传统技术处于活动状态，包括：
            <br> -- 所有用户在 Lightning Experience 中工作
            <br> -- Apex 中没有或很少使用 <code>@future</code> (使用Queueable)
            <br> -- 所有第三方 Apex 属于 AppExchange 软件包
            <br> -- 没有有效的工作流规则（使用流）
            <br> -- 没有有效的进程构建器进程（使用流）
            <br> -- PushTopic 事件（使用变更数据捕获）
            <br> -- 通用事件（使用平台事件）
            <br> -- 30.0 之前的 API 版本
            <br> -- Salesforce 组织连接使用适用于 Salesforce Connect 的跨组织适配器</td>
            <td><b>在您的组织中：</b>
            <br> - 不支持或原有技术已启用，包括：
            <br> -- 使用 Salesforce Classic 的用户
            <br> -- <code>@future</code> use in Apex
            <br> -- 来自非 AppExchange 源的第三方 Apex
            <br> -- 工作流规则
            <br> -- 进程构建器进程
            <br> -- PushTopic 事件
            <br> -- 通用事件
            <br> -- 30.0 之前的 API 版本
            <br> -- Salesforce 到 Salesforce 的连接</td>
        </tr>
    </tbody>
</table>

## 可读性

*可读性*的核心概念是创造一致性,使人们容易理解事物的工作方式。构建可读的系统会使交付和维护团队保持一致，并帮助不熟悉系统的人员快速了解零件如何组合在一起。这意味着您的团队可以更少地依赖具有机构或历史 Knowledge 的个人来有效地引导供应商或新的团队成员。这意味着团队中的熟练人员可以专注于正在做出的选择的质量和权衡，因为系统的配置和代码易于人类阅读和理解。可读性可以加快治理和质量保证流程，并帮助团队更好地识别何时创建冗余自定义。它还可以提高系统以可重用和可测试的方式运行的可能性。

您可以通过有效的设计标准和文档来提高可读性。

### 设计标准

[设计标准](/docs/architect/zh-cn/resources/guide/design-standards-template)提供了保持所有自定义一致的指导，即使在开发的早期阶段。设计标准就像护栏一样，使所有从事系统工作的交付团队和维护团队在如何处理和实施自定义方面保持一致。定义设计标准有助于提高交付和维护团队的效率，使代码和架构审查更容易进行，并为更好的[文档](/docs/architect/zh-cn/well-architected/guide/intentional#文档)提供基础。

如果没有设计标准，团队更有可能在竖井中工作。如果没有设计标准提供的一致性，企业将发现自己很难做到：

- 供应商和开发团队跨解决方案使用临时模式和方法，可能会引入反模式并降低可重用性(请参阅[关注分离](/docs/architect/zh-cn/well-architected/guide/composable#分离问题))。
- 增加了解决生产问题的时间，以及培训新团队成员所需的支持团队，并帮助他们了解一组不同的模式和方法。
- 跨团队协作不佳、团队之间工作冗余、解决冲突的时间浪费，以及集成测试中发现的错误。
- 增加挫折感和更高的更替率。

设计标准的一个关键优势来自利益相关者为创建标准而必须进行的对话和决策。特别是，该流程为您的业务和技术潜在客户提供了机会，让他们能够围绕业务所需的优化设计进行调整。

在[设计标准中](/docs/architect/zh-cn/resources/guide/design-standards-template)包含以下内容

- **Salesforce 元数据的命名约定**为如何命名系统中的每个自定义定义一组约定。良好的命名约定不仅仅是在对象、字段、代码、流和系统的其他元素的名称之间强制执行一致性。良好的命名约定也有助于开发团队使用名称来传达有关他们正在构建的内容的目的和功能的信息。因此，其他利益相关者可以通过查看其名称来更好地理解特定的自定义。
- **批准的设计模式及其用例**建立[模式和反模式浏览](/docs/architect/zh-cn/well-architected-tools/guide/patterns)器库，以及关于何时(和不使用)使用每个模式的关键信息。该库可能包括所需的 Apex 触发器模式，或基于您在系统中的可[组成性](/docs/architect/zh-cn/well-architected/guide/composable)的流编排模式。
- **开发环境和工具指导**。维护开发团队用于工作的明确工具列表。这可能包括为编写代码的任何人批准的工具链和语言，或者为低代码开发批准（或未批准）的声明性功能。您的标准可能包括用于自定义和文档的源控制系统列表，以及所需的签入/签出步骤。它们可能还包括用于不同类型开发工作的环境列表。

除了定义这些标准之外，您还需要决定如何以及在哪里维护和存储它们。如果贵公司的团队找不到您的设计标准（或者甚至不知道存在），它们将不会有效。理想情况下，您的设计标准与您的文档在同一个系统中（有关更多信息，请查看下一节）。

下面的[模式和反模式](/docs/architect/zh-cn/well-architected/guide/intentional#可读性模式和反模式)列表显示了 Salesforce 组织的正确(和糟糕)设计标准。您可以使用这些来验证或改进您的设计标准。

要了解有关可帮您定义设计标准的 Salesforce 工具的更多信息，请参阅[工具相关意图](/docs/architect/zh-cn/well-architected/guide/intentional#与意图相关的工具)。

### 文档

文档解释了系统的内容、方式和原因。如果没有有意义和一致的文档，团队会浪费大量时间来尝试了解系统的现状（并潜在地误解功能和自定义）。

创建好的文档需要时间。虽然大多数团队都认为文档对大型项目很重要，但在进行快速更改（例如配置更新或对自动化进行小的调整）时，跳过这一步可能很有诱惑力。不记录您对系统进行的更改始终是一种反模式。跳过文档可能会节省少量前期时间，但排除未正确记录的组织故障所需的时间将不仅仅是抵消这些节省时间。请始终在所有预估中包含足够的时间来创建文档，而不论您计划进行的更新需要付出多大的努力。

缺乏清晰的文档会导致各种问题，包括：

- 用于返工现有实施的开发周期
- 重复讨论重新讨论或对先前的决定感到困惑
- 新团队成员或供应商入职时间更长
- 过度依赖拥有机构或历史 Knowledge 的个人
- 冗余架构支持整个业务中相同或类似的功能
- 难以向关键利益相关者传达解决方案的目的和价值

对于 Salesforce 解决方案，维护文档：

- **解决方案概述**。通过[图表](/docs/architect/zh-cn/reference-diagrams/guide/introduction)，您和利益相关者能够以各种详细信息级别可视化解决方案。Salesforce 图表框架帮助您创建图表，显示解决方案的业务功能以及技术实施详细信息。
- **决策记录**。将考虑的选项、权衡、最终决策和推理记录在一个所有团队成员都可以访问的中心位置，以备将来参考。
- **代码**。代码格式本身是文档的关键部分，它可以(并且应该)与您的[设计标准](/docs/architect/zh-cn/well-architected/guide/intentional#设计标准)保持一致。您还需要记录关键信息，并在每次修改代码时进行更新。对于所有类、触发器和组件，请记录以下内容：
  - 代码的作者
  - 编写代码的时间
  - 代码应该做什么
  - 关键依赖性
  - 所有更改
- **声明性自定义**。对于贵组织中元数据的每种自定义，Salesforce 会为团队提供[内置属性](/docs/architect/zh-cn/fundamentals/guide/platform-multitenant-architecture#基于浏览器的无代码和低代码应用程序开发)，以提供有关元数据目的和意图的帮助信息。作为设计标准的一部分，包括团队如何使用这些内置功能，以及如何命名声明性自定义。还要维护与您用于代码的信息相同的关键信息日志。

制定一套文档标准，以确保所有当前和未来团队成员能够以同样的方式解释文档。 ([设计标准](/docs/architect/zh-cn/resources/guide/design-standards-template)可以帮助做到这一点。)考虑用户如何搜索文档以查找相关部分或术语也很重要。随着系统的老化和复杂性的增加，您的文档也会增加。文档中信息的用途将与用户搜索和查找相关项目的频率、速度和容易程度直接相关。

下面的[模式和反模式](/docs/architect/zh-cn/well-architected/guide/intentional#可读性模式和反模式)列表显示了 Salesforce 组织的正确(和糟糕)文档。您可以使用这些来验证或改进您的文档策略。

要了解有关适用于文档的 Salesforce 工具的更多信息，请参见[工具相关意图](/docs/architect/zh-cn/well-architected/guide/intentional#与意图相关的工具)。

### 可读性模式和反模式

下表显示了在您的组织中要查找（或构建）的模式的选择，以及要避免或针对补救的反模式。

✨ 在[模式和反模式浏览](/docs/architect/zh-cn/well-architected-tools/guide/easy-readability)器中，发现更多可读模式。

<table>
    <colgroup>
       <col span="1" style="width: 10%;">
       <col span="1" style="width: 45%;">
       <col span="1" style="width: 45%;">
    </colgroup>
    <tbody>
        <tr>
            <th scope="colgroup"></th>
            <th scope="colgroup">模式</th>
            <th scope="colgroup">反模式</th>
        </tr>
        <tr>
            <td rowspan="2"><b>设计标准</b></td>
            <td><b>在您的组织中：</b>
            <br> - 代码和声明性自定义具有一致的、人类可读的名称
            <br> - 数据模型的对象和字段名称一致、统一
            <br> - 审计显示字段在报表等中一致填写和引用。</td>
            <td><b>在您的组织中：</b>
            <br> - 代码和声明性自定义名称不一致
            <br> - 数据模型的名称不一致，许多对象和字段似乎多余
            <br> - 审计显示许多未使用的字段或各种使用级别，并且没有与报告等一致的链接。</td>
        </tr>
        <tr>
            <td><b>在您的业务中：</b>
            <br> - 团队知道使用（和不使用）什么工具完成工作
            <br> - 批准的设计模式易于按用例查找和识别
            <br> - 批准的 AI 模型被明确识别，并包含预期目的</td>
            <td><b>在您的业务中：</b>
            <br> - 团队使用许多不同的工具完成类似的工作
            <br> - 没有批准的设计模式
            <br> - 供应商或新员工入职需要大量时间
            <br> - 批准的 AI 模型未明确识别，预期目的不明确</td>
        </tr>
        <tr>
            <td rowspan="2"><b>文档</b></td>
            <td><b>在您的组织中：</b>
            <br> - 代码和声明性自定义有明确的描述</td>
            <td><b>在您的组织中：</b>
            <br> - 代码和声明性自定义没有描述，有难以理解的描述，或描述似乎与自定义的实际功能不匹配</td>
        </tr>
        <tr>
            <td><b>在您的业务中：</b>
            <br> - 所有解决方案都有业务功能和技术实施详细信息的图表
            <br> - 为代码和声明性自定义设置关键信息日志
            <br> - 人员可以搜索并查找相关文档</td>
            <td><b>在您的业务中：</b>
            <br> - 解决方案的内容/方式/原因很难找到，并且可能对大多数团队不可用
            <br> - 人们很难理解解决方案和他们正在使用的系统
            <br> - 供应商或新员工入职需要大量时间</td>
        </tr>
    </tbody>
</table>

## 与意图相关的工具

<table class="tools-table"><tbody><tr><th>工具</th><th>描述</th><th>策略</th><th>可维护性</th><th>可读性</th></tr>
<tr><td><a href="https://github.com/SalesforceFoundation/ApexDoc">ApexDoc</a></td><td>包含静态 HTML 页面的文档 Apex</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col">X</td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.fields_picklist_delete_inactive_values.htm&language=en_US&type=5&_ga=2.216886358.1142927923.1683068265-1808100124.1682614163">批量删除无效选项列表值</a></td><td>从选项列表中删除无效未使用的值</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://www.lightningdesignsystem.com/tools/validator/">Lightning设计系统验证器</a></td><td>验证标记并了解如何改进代码</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col">X</td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=release-notes.rn_automate_flow_mgmt_migrate_to_flow_tool.htm&type=5&release=242&_ga=2.180751207.1142927923.1683068265-1808100124.1682614163">迁移到流</a></td><td>将工作流规则和进程构建器进程转换为流</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://appexchange.salesforce.com/appxListingDetail?listingId=a0N3u00000MRsKnEAL">Salesforce Labs 的项目管理工具</a></td><td>在 Salesforce 组织中管理项目</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://marketplace.visualstudio.com/items?itemName=salesforce.salesforcedx-vscode-expanded">适用于 Visual Studio 代码的 Salesforce 扩展（展开）</a></td><td>使用 Visual Studio 代码扩展高效分析 Salesforce 代码</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col">X</td></tr>
<tr><td><a href="https://sfdc.co/OrgCheck">组织检查</a></td><td>快速分析您的组织及其技术债务</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://github.com/forcedotcom/code-analyzer">Salesforce 代码分析器</a></td><td>通过 IDE、CLI 或 CI/CD 扫描代码，以确保符合最佳实践</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col">X</td></tr>
<tr><td><a href="https://architect.salesforce.com/roadmaps/roadmap-explorer">Salesforce 路线图资源管理器</a></td><td>探索 Salesforce 产品创新</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.admin_monitorsetup.htm&type=5">设置审计跟踪</a></td><td>跟踪设置更改和审计历史</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr>
</table>

## 与意图相关的资源

<table class="tools-table"><tbody><tr><th>资源</th><th>描述</th><th>策略</th><th>可维护性</th><th>可读性</th></tr>
<tr><td><a href="https://www.salesforce.com/blog/documentation-strategies-to-improve-your-salesforce-org/">改进 Salesforce 组织的 5 个文档策略</a></td><td>改进 Salesforce 实施文档</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://trailhead.salesforce.com/content/learn/modules/success-cloud-coding-conventions/choose-naming-conventions-sc">选择命名约定 (Trailhead)</a></td><td>了解如何应用命名约定</td><td class="check-col"></td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://medium.com/salesforce-architects/defining-identifying-and-measuring-technical-debt-5f783e2b381d">定义、识别和衡量技术债务</a></td><td>定义、识别和衡量技术债务</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="/docs/architect/zh-cn/resources/guide/design-standards-template">设计标准模板</a></td><td>为您的组织创建设计标准</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col">X</td></tr>
<tr><td><a href="/diagrams">Salesforce 图表入门</a></td><td>了解如何为您的用例创建正确的图表</td><td class="check-col"></td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://trailhead.salesforce.com/content/learn/modules/success-cloud-coding-conventions/get-started-with-coding-conventions-sc">编码惯例入门 (Trailhead)</a></td><td>定义并遵循编码约定</td><td class="check-col"></td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://trailhead.salesforce.com/trailblazer-community/download/file/0693A000006PskRQAS">如何处理技术债务 (Trailhead)</a></td><td>在 Salesforce 组织中管理技术债务</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://trailhead.salesforce.com/content/learn/modules/success-cloud-coding-conventions/improve-your-apex-code-sc">改进 Apex 代码 (Trailhead)</a></td><td>应用测试驱动开发的基本原则</td><td class="check-col"></td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://trailhead.salesforce.com/content/learn/modules/manage_the_sfdc_organizational_alignment_v2mom?trailmix_creator_id=strailhead&trailmix_slug=prepare-for-your-strategy-designer-credential">组织调整 (Trailhead)</a></td><td>了解 V2MOM 校准流程</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://medium.com/salesforce-architects/prioritizing-and-planning-a-way-out-of-technical-debt-6f18fbb2b007">优先考虑并计划摆脱技术债务的方法</a></td><td>制定减少和删除技术债务的计划</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://salesforce.quip.com/MW5cAPVwat8k#JCIACA8Q963">Salesforce 命名约定模板</a></td><td>开始使用命名约定</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col">X</td></tr>
<tr><td><a href="https://admin.salesforce.com/blog/2021/tech-debt-what-it-is-and-why-you-should-care">技术债务：它是什么以及您为什么要关心它？</a></td><td>了解技术债务对贵组织的影响</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://medium.com/salesforce-architects/using-the-business-model-canvas-in-enterprise-architecture-5c136803a99d">在企业架构中使用业务模型画布</a></td><td>在业务模型中创建、交付和查看价值</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
</table>

## 告诉我们您的想法

帮助我们保持 Salesforce 架构合理与您相关；参加我们的[调查](https://sfdc.co/bxNtvh)，以提供有关此内容的反馈，并告诉我们您接下来想要看到的内容。