可组合系统：
## 分离问题
*关注点分离*是软件工程和系统架构中的一个基本概念,它要求在一个更大的系统中识别各种关注点,这些关注点可以分为模块单元。要在系统中实现问题的强烈分离，需要为整个系统的应用程序逻辑和功能创建有意义的单元。更小的单元使应用程序交付和维护团队更容易理解如何以及在哪里进行更改，而对更大的系统的中断最少。更小的单元还使得解决[技术债务](/docs/architect/zh-cn/well-architected/guide/intentional#技术债务)时如何以及在哪里集中工作变得更加清晰，并有助于提高系统的整体[可读性](/docs/architect/zh-cn/well-architected/guide/intentional#可读性)。
通过面向业务能力和管理状态，您可以将问题更好地分离到您的 Salesforce 组织中。
### 功能单元
对于 Salesforce 系统，分离问题的最佳方式是应用面向业务的视角来识别和组织系统中的模块化单元（或功能）。这与专注于工程的视图不同，后者根据单位的技术功能来识别单位。分离问题的面向业务的视角需要根据代码和自定义为业务和业务用户提供的服务来组织系统中的代码和自定义。采取这种方法并不意味着忽略系统中冗余或重复技术功能的可能性。相反，这意味着技术服务被清楚地映射到最终对业务透明的组织原则。
面向业务功能有助于确保业务分析和发现团队与交付团队之间的交接尽可能简单。如果应用程序构建者不知道他们的工作单位映射到您的可组合架构中的位置，您会看到一团糟，而不是可组合的应用程序环境。业务所需的最终状态与组织中模块化单元之间的映射不明确，也会增加开发团队或供应商在系统中构建冗余功能的可能性。
请考虑以下事项，以将职能单位定向到业务能力：
- **从要完成的工作开始**。关注用户和业务本身要完成的工作 (JTBD)。JTBD 方法由 Tony Ulwick 倡导，它侧重于理解人们试图通过使用产品或服务实现的“工作”或真正目的。它比用户的角色相关任务或业务流程中的单个步骤更抽象。例如，重复检查和地址验证等任务可能属于“建立客户的单一视图”的更高级别功能。在您清楚了解这些更高级别的业务功能后，您可以开始将系统的一部分映射到它们。
- **面向功能，而不是报告结构**业务部门的内部层次结构不是有意义的功能或要完成的工作的代理。业务的内部层次结构的确对流程和团队结构有重大影响（更不用说预算了）。这些都是重要的后勤考虑。但业务的功能需求在比物流更高的抽象级别上运作。如果您正在创建模块来为报表结构提供服务，而不是为更高级别的功能提供服务，请注意，您可能必须采取额外的步骤来确定该模块与业务功能的关系。
- **迭代**。从与企业合作开始，确定哪些功能可用于最低可行产品 (MVP)。在您确定功能时，开始构建该 MVP。在构建时，确定对您正在创建的功能单元至关重要的流程、元数据和[事件或消息](/docs/architect/zh-cn/well-architected/guide/composable#消息传递和事件)。识别任何具有外部依赖性的进程、元数据和事件或消息。随着更多功能单元的设计,实施 [API 管理](/docs/architect/zh-cn/well-architected/guide/composable#api-管理)和[依赖性管理](/docs/architect/zh-cn/well-architected/guide/composable#依赖性管理)来构建彼此良好协作的单元(而不是构建孤立的单元 ) 。
以下[模式和反模式](/docs/architect/zh-cn/well-architected/guide/composable#关注模式和反模式分离)列表显示了 Salesforce 解决方案中业务功能的正确(和不佳)方向。您可以在构建之前使用这些来验证您的设计，或者确定您的系统需要重构的区域。
要了解有关 Salesforce 可用工具的更多信息，以帮助您更好地定位业务功能，请参阅[相关工具](/docs/architect/zh-cn/well-architected/guide/composable#与可撰写相关的工具)。
### 状态管理
状态管理以整个系统中不同时间点的信息移动为中心。有效的状态管理使应用程序能够以最少的计划外或不确定的结果处理复杂的数据流或交互。在模块化 Salesforce 组织中管理状态意味着为单位内部和单位之间的逻辑流构建清晰的路径，以及为计划外的执行行为构建优雅的路径。通过状态管理，可以从模块化 Salesforce 应用程序单元形成一致的逻辑流。在大多数情况下,这需要[互操作性](/docs/architect/zh-cn/well-architected/guide/composable#交互性)来构建单位之间的信息流。
松耦合单元之间管理状态的困难通常会导致 Salesforce 中的单片应用程序开发。您可以在大型“单层流”中看到这一点，这些“单层流”是为了在单个流中编排复杂的流程而构建的。另一个例子是大型 Apex 类 , 它们通过*意大利面代码* , 或一长串一次性方法来编排复杂的过程。这些类型的应用程序架构使重构和调试变得困难，并增加了新团队成员或供应商的入职时间。它们还降低了交付给企业的应用程序的价值，因为功能不可重复使用。
考虑以下事项，以在模块化 Salesforce 组织中管理状态：
- **决定何时使用有状态与无状态模式。**有状态模式会保留整个执行路径中的信息，而无状态模式不会。在松耦合的系统中，无状态模式使得组件的重构更快，副作用更少。然而，无国籍模式并非适用于所有用例。如果您正在为数据操作构建组件，状态模式有助于整个系统的数据完整性和一致性。如果您的组件满足以下任何条件，请使用有状态模式：
- 了解放置在更大的执行路径中对于组件的行为至关重要
- 组件的行为需要根据下游操作的结果进行更改（例如，需要根据下游组件的回滚/错误/成功消息更改执行）
- 组件需要等待来自外部或下游系统的响应才能完成工作
- **为状态信息创建有意义的类别。**_State_ 是一个模糊的术语，可以应用于 Salesforce 组织内部(及外部)如此广泛而深入的信息，以至于该术语本身几乎没有意义。因此,构建有状态模式的必要第一步是为系统中最重要的有状态执行路径(或各种有状态行为)创建有*意义*的类别。需要考虑的一些类别：
- 导航和表单
- 数据库操作
- 批处理和批量操作
- 错误
- **从数 [据库事务](/docs/architect/zh-cn/fundamentals/guide/architecture-basics#数据库操作)的角度定义数据相关的状态**。平台的内置行为将限制 Salesforce 中数据的大多数状态注意事项。请勿尝试针对或规避此行为。为它设计并使用它。设计最小化或消除分布式事务逻辑的解决方案。（有关更多详细信息，请参阅[数据处理](/docs/architect/zh-cn/well-architected/guide/automated#数据处理)）。
- **识别功能单元内部(和之间)发生的状态。**当您将功能单元组装成更大的系统时，请注意您何时混合了无状态和有状态的组件行为，并防止可能在处理中产生无限循环或间隙的组合。
- **定义切换**。请考虑组件将使用什么[消息传递或事件](/docs/architect/zh-cn/well-architected/guide/composable#消息传递和事件)模式将状态相关数据传输到系统的另一个部分。确保您正在将事务意识和[处理](/docs/architect/zh-cn/well-architected/guide/automated#数据处理)构建到组件中。请勿在切换中包含任何分布式事务逻辑。
- **创建进程图和状态之间的映射。**进程图详细说明了在不同时间点通过系统移动信息的步骤。状态图显示了信息（状态）的实际变化。使用 [Salesforce 图表](/docs/architect/zh-cn/reference-diagrams/guide/kit-of-parts)形状的元数据页脚部分来捕获流程中每个步骤中不断变化的信息状态。如果您分开进程图和状态图，请确保将它们链接起来。不应将这一概念与在设计和实施期间捕获流程或系统总体状况的当前和未来状态混淆，因为这与在系统中移动的信息无关。
下面的[模式和反模式](/docs/architect/zh-cn/well-architected/guide/composable#关注模式和反模式分离)列表显示了 Salesforce 解决方案中正确(和糟糕)的状态管理。您可以在构建之前使用这些来验证您的设计，或者确定系统中需要重构的地方。
要了解有关用于管理状态的 Salesforce 工具的更多信息，请参见[工具相关可撰写](/docs/architect/zh-cn/well-architected/guide/composable#与可撰写相关的工具)。
### 关注模式和反模式分离
下表显示了在您的组织中要查找（或构建）的模式的选择，以及要避免或针对补救的反模式。
✨ 在[模式和反模式探索](/docs/architect/zh-cn/well-architected-tools/guide/adaptable-separation-of-concerns)器中，发现更多关注分离的模式。
| 模式 | 反模式 | |
|---|---|---|
| 功能单元 | 在设计标准中：
- 命名约定解决了如何表示功能单元的问题 - 存在所有当前定义的功能单元（和相关命名约定）的列表 - 存在提议增加或更改职能单位的标准 |
在设计标准中：
- 设计标准不存在或未涉及功能单元和用例 |
| 在您的文档中：
- 系统横向图清楚显示组织中的功能单元 - 所有文档和实施图表都清楚地显示了组件的功能单元 - 单个组件的文档包含组件的功能单元映射 - 功能单元中的所有组件均可搜索并易于查找 |
在您的文档中：
- 组件文档不存在 - 组件文档描述了组件所属的功能单元，但这是该功能单元定义出现的唯一位置 - 您无法搜索特定功能单元和/或搜索无助于识别功能单元中的所有组件 |
|
| 在您的组织中：
- 可以快速识别指定元数据的功能单元对齐方式（例如，流、Apex 类或 Lightning 页面） - 职能单位使用业务友好术语进行标记 |
在您的组织中：
- 无法识别任何元数据的功能单元对齐 - 职能单位信息不一致或不准确 - 功能单元信息使用对业务用户毫无意义的工程术语进行标记 |
|
| 状态管理 | 在设计标准中：
- 有状态设计与无状态设计的用例很清楚 - 存在批准的无国籍通信模式 - 存在状态通信的批准模式 - 州/省的清除类别已存在 |
在设计标准中：
- 设计标准不存在或未处理状态/无国籍模式和用例 |
| 在您的文档中：
- 每个处理有状态和/或无状态通信的组件都指示已实施什么模式 - 可以搜索和查找实施特定有状态/无状态模式的所有组件 - 进程和交互图表提供有关状态类别和切换的详细信息 |
在您的文档中：
- 组件文档不存在 - 组件文档描述了实施的有状态/无状态模式，但这是定义出现的唯一位置 - 无法搜索特定模式和/或搜索无助于识别使用该模式的所有组件 |
|
| 在 Apex 中： - 保存点和回滚行为用于所有数据操作 |
在 Apex 中： - 不使用保存点和回滚行为 |
|
| 在流中： - 错误路径和使用回滚记录元素 |
在流中： - 未使用回滚记录元素 |
| 模式 | 反模式 | |
|---|---|---|
| 消息传递和事件 | 在设计标准中：
- 对于何时使用同步模式（消息传递）和异步模式（事件），存在明确的标准 - 事件和消息结构存在明确的标准 |
在设计标准中：
- 设计标准不存在，或者缺乏同步与异步模式的明确标准，以及消息或事件结构的明确标准 |
| 在您的组织中：
- 用于内部系统消息传递的平台事件被清楚地标记 - Salesforce 流工具引用全系统消息传递或事件服务 - 一致的消息传递和事件模式出现在流和代码中 |
在您的组织中：
- 用于内部系统消息传递的平台事件未明确标记或不存在 - 流和代码中出现不同的消息传递和事件模式策略 |
|
| 在 Apex 或 LWC 中：
- 自定义事件定义的范围有限（代码中未定义系统范围的事件或消息） - Apex 中的系统范围消息传递或事件服务以使它们在 Salesforce 流工具中可用的方式注释 |
在 Apex 或 LWC 中：
- 系统范围的消息和/或事件结构在 Apex 或 JavaScript 中定义 - Apex 中定义的系统范围事件或消息结构在流等工具中不可用 |
|
| API 管理 | 在设计标准中：
- 存在跨组件通信的清除协议（即 API） - 协议/API 在生成器可以搜索和查找的逻辑组中概述 - 协议/API 定义了变量数据类型、变量名称、必填或可选内容，并清楚地描述了何时使用 |
在设计标准中：
- 设计标准不存在或未定义 API 和用例 |
| 在您的文档中：
- 每个组件的文档都清楚地列出了哪些 API/通信协议已经实施 - 可以搜索特定 API 或协议，并确定实施该协议的组件 |
在您的文档中：
- 组件文档不存在 - 组件文档描述了在组件中实施的 API，但这是 API 定义出现的唯一位置 - 无法搜索特定 API 或协议和/或搜索无助于识别已实施 API 或协议的组件 |
|
| 在您的组织中：
- 内部通信的 API 消息格式和变量使用自定义元数据类型定义 - 内部通信的 API 消息格式和变量由平台事件定义 - 代码和声明性自定义引用适当的自定义元数据类型（或平台事件），以便发送或接收信息 |
在您的组织中：
- 系统组件之间的通信（代码和声明性自定义）是临时的 - API 专为 Salesforce 与外部系统之间的通信定义 |
不论您选择的软件包组织模式如何，请记住一些绝对值：
- **请勿在软件包之间重复元数据。**多个软件包需要的元数据应抽象为一个或多个声明为依赖项的软件包。
- **利用 Salesforce Platform 元数据的内置依赖性。**对于应用程序生成器，Salesforce Platform 提供的内置服务提供了大量可以快速配置的功能。其中许多服务具有内置的依赖性，使它们难以抽象为低级别的功能单元。对于给定的元数据类型，您需要了解它在[内置依赖关系](https://developer.salesforce.com/blogs/2018/06/lets-talk-deployment-and-reasons-why-they-succeed-or-fail)中所处的位置，并使用这种了解来[定义软件包依赖](https://developer.salesforce.com/blogs/2018/06/working-with-modular-development-and-unlocked-packages-part-2)链。不要通过尝试将松散耦合强制纳入具有大量内置依赖性的标准平台功能来开始软件包采用。当您达到更高的功能时，它将增加复杂性（而不是价值）。这也是另一种归入[标准和自定义](/docs/architect/zh-cn/well-architected/guide/intentional#标准与自定义功能)[反模式](/docs/architect/zh-cn/well-architected/guide/intentional#可维护性模式和反模式)的方法。从底部（最低的依赖性）向上封装元数据，并随着时间的推移进行迭代。
- **留意依赖链**。避免创建软件包依赖链，这将要求开发人员在任何时候将他们所做的更改拆分成许多不同的软件包。
- **想想什么对源控制有意义**在源控制中管理软件包有两种基本方法。第一个是单个*monorepo*，软件包隔离在文件夹中。第二个是多个存储库，软件包隔离在自己的存储库中。长期管理每种源策略都很复杂。就开发人员入门而言，垂直边界在多个存储库模式中效率更高。水平边界在单层建筑中更容易理解。同样，随着架构的成熟，您可以混合和匹配策略。
下面的[模式和反模式](/docs/architect/zh-cn/well-architected/guide/composable#可封装性模式和反模式)列表显示了 Salesforce 软件包中正确(和差)的依赖管理是什么样子的。您可以在构建之前使用这些来验证您的设计，或者确定您的系统需要重构的区域。
要了解有关适用于依赖管理的 Salesforce 工具的更多信息，请参阅[工具相关可撰写](/docs/architect/zh-cn/well-architected/guide/composable#与可撰写相关的工具)。
### 可封装性模式和反模式
下表显示了在您的组织中要查找（或构建）的模式的选择，以及要避免或针对补救的反模式。
✨ 在[模式和反模式探索](/docs/architect/zh-cn/well-architected-tools/guide/adaptable-packageability)器中，发现更多可封装性模式。
| 模式 | 反模式 | |
|---|---|---|
| 松耦合 | 在设计标准中：
- 命名约定解决了如何表示软件包单位的问题 - 可以搜索并查找所有当前定义的软件包单元（和相关命名约定）的列表 - 存在建议软件包单元添加或更改的标准 -（可选）自定义设置的所有批准的用例都清楚地列出（如果有） |
在设计标准中：
- 设计标准不存在或未处理软件包单元和用例 |
| 在您的组织中：
- 自定义元数据类型为代码和声明性自定义提供动态运行时信息 - 不存在自定义设置或自定义设置很少，并且没有与封装功能相关的设置 - 不存在自定义对象，以便为代码或声明性自定义提供动态运行时信息 |
在您的组织中：
- 使用自定义设置 - 自定义对象的存在是为了提供代码或声明性自定义的动态运行时信息 - 自定义元数据类型未用于（或未一致使用）为代码和声明性自定义提供动态运行时信息 |
|
| 在 Apex 中：
- 使用抽象或虚拟 Apex 类定义常见服务和模板代码 - 依赖于动态运行时信息的方法引用适当的自定义元数据类型 |
在 Apex 中：
- 常见服务和模板代码不易与其他类区分 - 跨类和方法的内部引用难以遵循，并且在整个代码库中不一致 - 方法没有使用一致的方法来访问动态、运行时信息，或者方法没有查询运行时行为信息的自定义对象，或者代码引用自定义设置 |
|
| 在源控制和开发环境中：
- package.xml 文件仅出现在早期阶段或概念验证项目清单中 |
在源控制和开发环境中：
- package.xml 文件用于控制元数据部署 |
|
| 在软件包中：
- 依赖于组织的解锁软件包仅用于早期阶段或概念验证实验 - 在生产或 Sandbox 中未定义非受管软件包 |
在软件包中：
- 所有软件包都是依赖于组织的解锁软件包 - 非受管软件包在生产或 Sandbox 中定义 |
|
| 依赖性管理 | 在设计标准中：
- 存在声明依赖性的标准 - 存在引入或修改依赖性的标准 |
在设计标准中：
- 设计标准不存在或未涉及如何声明依赖性 |
| 在源控制中：
- 解锁软件包的软件包版本使用别名 ( LATEST) 在 sfdx-project.json 清单中声明依赖性
- 开发人员可以从源代码控制中创建临时组织并成功部署软件包元数据 |
在源控制中：
- 解锁软件包的软件包版本在 sfdx-project.json 清单中明确声明（无 lateST 别名）
- 开发人员无法使用源代码控制成功使用临时组织 |
|
| 在软件包中：
- 软件包之间没有重复的元数据 - 对于软件包开发，所有早期开发工作都在临时组织中进行 |
在软件包中：
- 通过在不同软件包中复制元数据来规避依赖性 - 早期软件包开发发生在 Developer Sandbox 中，或者早期软件包开发不能发生在临时组织中 |
|
| 另请参阅：松耦合 | ||
| 工具 | 描述 | 分离问题 | 交互性 | 可打包性 |
|---|---|---|---|---|
| Apex REST Web Services | 通过 REST 向外部应用程序公开 Apex 类和方法 | X | ||
| Apex SOAP Web Services | 通过 SOAP 向外部应用程序公开 Apex 类和方法 | X | ||
| 变更数据捕获 | 将更改发布到 Salesforce 记录 | X | ||
| 自定义元数据类型 | 定义可重用、可自定义、可封装的功能 | X | ||
| 装饰师 | 将函数或属性公开为 api | X | X | |
| Dev Hub | 管理临时组织、第二代软件包和 Einstein 功能。 | X | X | X |
| 通用事件（传统）* | 发送与 Salesforce 数据更改无关的自定义事件 | X | ||
| Lightning数据服务 | 跨组件缓存和共享数据 | X | X | |
| Metadata API | 在 Salesforce 环境之间部署自定义 | X | ||
| 元数据覆盖范围报表 | 确定几个渠道之间支持的元数据覆盖范围 | X | ||
| MuleSoft Composer | 使用单击而不是代码为数据构建流程自动化 | X | ||
| 出站消息 | 在更新字段值时向外部端点发送消息 | X | ||
| 平台事件 | 发送包含近乎实时事件数据的安全和可扩展的消息 | X | ||
| 发布/订阅 API | 订阅平台事件、变更数据捕获或实时 Event Monitoring | X | ||
| PushTopic 事件（原有）* | 发送和接收与用户定义的 SOQL 查询匹配的数据变更通知 | X | ||
| Salesforce CLI | 与 Salesforce 组织协作时开发和构建自动化 | X | ||
| Salesforce Diagrams | 创建图表以显示业务功能和技术详细信息 | X | ||
| 适用于 Visual Studio 代码的 Salesforce 扩展（展开） | 适用于 Salesforce 开发的官方 VS Code 扩展 | X | ||
| 临时组织 | 将 Salesforce 代码和元数据部署到一次性组织 | X | ||
| 第二代受管软件包 | 为 AppExchange 开发和分发应用程序 | X | ||
| 工具 API | 为 Lightning 平台应用程序构建自定义开发工具或应用程序 | X | ||
| 解锁的软件包 | 组织元数据、封装应用程序或扩展 AppExchange 应用程序 | X | ||
| *Salesforce 将继续在当前功能范围内支持 PushTopic 和通用事件，但不打算对此技术进行进一步投资。 | ||||
| 资源 | 描述 | 分离问题 | 交互性 | 可打包性 |
|---|---|---|---|---|
| 对数字集成的初步了解 | 为连接概念开发通用语言 | X | ||
| 将域驱动的设计应用于 Salesforce | 围绕业务功能定位解决方案 | X | ||
| 第二代软件包的最佳实践 | 了解 2GP 打包模式和实践 | X | ||
| 受管软件包中可用的组件 | 了解受管软件包元数据组件 | X | ||
| 设计标准模板 | 为您的组织创建设计标准 | X | X | X |
| 事件驱动架构决策指南 | 比较事件驱动的架构模式和工具 | X | ||
| 事件反模式 | 确定使用事件时要避免的反模式 | X | ||
| 如何设计消息驱动和事件驱动的 API | 阅读 MuleSoft 开发指南中的差异 | X | X | |
| 了解要完成的作业框架 | 在 Trailhead 上探索 JTBD | X | ||
| 在 B2C Commerce 中管理全球状态 | 在组件之间轻松传递数据以保持状态 | X | ||
| 消息传递指南 | 交流相关信息，创造欢乐时刻 | X | ||
| 消息传递类型 | 根据用户交互的性质了解不同的消息传递类型 | X | ||
| 元数据类型 | 了解 Salesforce 组织中不同类型的元数据 | X | X | |
| 移动应用程序通知类型 | 了解 Salesforce 移动应用程序的通知类型 | X | ||
| 优化视图状态 | 在 Visualforce 页面中维护状态 | X | ||
| Salesforce 开发人员体验 (DX) | 在 Lightning 平台上管理和开发应用程序 | X | X | X |
| 不支持的元数据类型 | 识别在元数据 API 中不可用的组件 | X |