探索如何在实际商业逻辑时应用明确的原则，从而维护 Adobe Commerce 架构，利用它来有效应对电子商务的固有复杂性。
简介
Adobe Commerce 以其强大与灵活性而广为人知。然而，市场往往低估了有效管理这种强大能力所需的责任。
从领域驱动的设计角度来看，电子商务由多个限定领域组成，如目录、定价、库存、结账和订单管理。每个领域都有自己的规则、状态和故障模式。因此，电子商务在设计上必然是一个复杂领域。
因此，挑战不在于如何消除复杂性，而在于如何有意地管理复杂性。本文中概述的原则旨在帮助 Adobe Commerce 实施以受控、可扩展和可持续的方式处理复杂性。
原则 1：复杂性应源于设计，而非意外产生
在电子商务中，复杂性是与生俱来的。但是，它应该显现为对实际业务需求的有意回应，而不是实施过程中的意外副作用。
Adobe Commerce 的核心功能旨在通过结构化和可扩展的架构基础来支撑电子商务领域的固有复杂性。平台本身不是复杂性的来源；它是解决方案的一部分。
当该领域固有的复杂性与结构不良的商业逻辑或临时自定义结合起来时，真正的挑战就出现了。在这种情况下，实施决策（而非业务要求）成为系统行为的主要驱动因素。
在实践中，成功的实施会明确区分以下几点：
- 电子商务固有的不可避免的复杂性
- 在 Adobe Commerce 中实施业务规则和自定义的方式
当复杂性是有意设计的结果时，随着平台的发展，职责仍能保持清晰、交互明确且系统行为也可预测。
示例：客户 A 位于伦敦，而企业运营着两个仓库。一种常见的实施方式是，通过允许发货逻辑根据客户位置比较各个仓库的成本，然后选择最便宜的选项，以此来计算发货成本。尽管这看起来可能很高效，但它悄悄地将履行决策转移到发货逻辑中，导致系统行为由实施路径驱动，而不是明确的业务规则。
正确的设计是让 MSI 根据库存可用性和采购优先级有意识地确定履行方案。这些决策可能还会考虑客户的地点。然后，发货环节应仅比较由 MSI 选择的一个或多个仓库的费率，并选择最便宜的选项。这便将复杂性保留在它所属的业务领域内，而不是将其隐藏在自定义代码中。
意外导致的复杂性（忽略 MSI 决策）
设计的复杂性（使用 MSI 决策）
原则 2：扩展能力，而不是复杂性
许多组织在开发、工具、团队成长和基础架构方面投入了大量资金，但仍难以实现业务目标。
雇用新团队来弥补规划和实施上的不足可能有助于解决部分问题，但也会引发更多新问题。仅靠雇佣团队并不能解决问题。新团队往往继承了同样有缺陷的结构和架构决策，这限制了发展，并使协调成本成倍增加。
同样，增加基础架构容量以弥补低效的实施或许能带来暂时的缓解，但也增加了成本和操作复杂性。久而久之，这会导致交付速度变慢、集成变得脆弱以及持续的救火式工作。
扩展应侧重于改进架构功能、明确边界、可预测的行为和灵活的集成，而不是通过增加人员或基础架构来掩盖结构性问题。
原则 3：让故障安全可控，而非悄无声息地发生
在架构或生产审计期间，经常会发现客户历程中从未报告过的故障请求，有时甚至会发生在操作工作流中，并且在某些情况下根本未被测试所检测到。这些故障可能会在结账、支付确认或库存验证期间发生，但却没有留下可供团队采取行动的清晰信号。这不仅仅是技术债务；在电子商务中，悄无声息的故障直接阻碍了增长，侵蚀了信任。
安全的失败意味着系统会以受控和明确的方式作出响应：
- 错误对运营团队可见
- 客户会收到明确而恰当的反馈
- 系统状态保持不变
- 恢复路径已明确定义
在电子商务实施中，该原则对于结账、支付、库存同步和异步流程尤其重要。可见的故障让团队能够快速采取行动；无声的故障让问题在无人察觉的情况下不断恶化。
设计安全的故障处理模式，能将事故转变为可控事件，而非影响业务的意外。
如何针对订单创建操作设计安全的故障处理模式
通过将故障视为每个关键流程的明确结果，来设计安全的故障处理模式。对于结帐和创建订单，提前决定系统记录的内容、向客户显示的内容以及在出现问题时如何向团队发送警报。一次安全的故障会将系统置于已知状态，适当通知客户，并提示运营团队进行恢复。当有意设计这些路径时，故障是可控且可处理的；反之，故障会默认变得悄无声息。
原则 4：逐步推出，并计划好回滚方案
电子商务系统的更改不可避免。必须不断推出新功能、集成、性能改进和业务规则。风险不在于进行大量更改，而在于部署这些更改时缺乏控制或恢复路径。
大型一次性部署会显著增加故障的爆发范围（即安全事故在组织内可能造成的影响）。当出现问题时，团队经常被迫进行紧急修复、部分回滚或手动数据更正，所有这些都会带来额外的风险。
逐步推出通过限制影响来减少此风险：
- 更改以递增方式引入
- 在真实流量下验证行为
- 及早隔离故障
计划好回滚方案同样重要。在设计期间就应当考虑回滚，而不是在发生事故后才去考虑。它不应该是一种紧急反应，而应该是一种精心设计的能力。利用配置标志、版本化 API 和向后兼容的更改，团队可以禁用或还原功能，而不会导致整个系统运行中断。
在 Adobe Commerce 实施中，此方法对于结账逻辑、定价规则、集成和异步工作流（如消息队列）尤其有用。受控的推出与明确的回滚路径相结合，使团队能够更快地开展工作，同时降低运营风险。
带有计划好的回滚方案的逐步推出，将部署工作从高风险事件转变为可管理和可重复的过程。
回滚应降低风险
逐步发布更改以确保可以快速关闭它们。如果停止更改的过程缓慢或复杂，则说明回滚设计不正确。
原则 5：解耦集成；集中化可观察性
现代电子商务实施很少孤立运行。它们依赖于多种外部系统，如 ERP、OMS、支付服务提供商、发货服务和分析平台。这些集成的设计方式直接影响到系统的稳定性和可操作性。
紧密耦合的集成会催生脆弱的系统。当一个外部依赖项速度减慢或发生故障时，可能会阻塞关键客户流程，例如结账或下单。随着时间的推移，这种耦合会增加运营风险，并限制更改或扩展单个组件的能力。
解耦集成通过以下方式降低这种风险：
- 隔离系统之间的故障
- 在适当的情况下允许异步通信
- 在不阻塞核心流程的前提下启用重试与恢复机制
然而，光靠解耦是不够的。没有集中化的可观察性，故障就会消失在视线之外。
集中化的可观察性确保团队能够了解整个系统中正在发生的情况：
- 集成故障可见且可跟踪
- 影响业务的事件是可衡量的
- 可以跨服务和领域对问题进行关联分析
在 Adobe Commerce 系统中，解耦的集成与集中式可观察性相结合，使团队能够安全地扩展集成，同时保持对系统行为的控制。
真正的风险不在于集成失败本身，而在于对解耦后的系统缺乏可见性。这一原则将集成从隐藏的风险源转变为架构中可管理且可观察的一部分。
解耦以实现弹性，集中以便管控
将集成解耦，以便使核心业务流程在面对外部系统的延迟或故障时仍能保持弹性。同时，集中化可观察性通过将所有集成事件、故障和延迟都显示在一个位置来保持对架构的控制。通过解耦，可缩小爆发半径（即破坏的影响范围）；集中化可观察性则确保系统保持可理解、可操作和安全演进的状态。
原则 6：设计背压
系统必须尊重下游容量。当依赖项变得缓慢或饱和时，上游组件应减少负载、推迟非关键工作并应用有限制的重试。
缓冲机制（如队列、定时任务积压、线程池和数据库写入）是为了平缓短期峰值，而非充当无限制的存储空间。关键用户流程必须通过有意且优雅的降级保持响应能力。
在基于消息队列的系统中实施时，如果下游使用者无法跟上节奏，则消息生产应该减慢速度或暂停。队列旨在吸收短期的峰值，而不是积累无限制的积压任务。必须通过速率限制、流量控制和重试次数限制在源头控制负载。发布者在发送消息之前应观察队列运行状况和使用者容量信号，避免因队列可用性问题阻塞关键业务流程。
背压可保护生产者和消费者
背压是一个架构问题。无论 Adobe Commerce 是充当生产者还是使用者，都必须管理负载，以便将重试和积压任务保持在有限且可观察的范围内。
原则 7：证据重于假设
考虑假设，但要以证据为先。
随着系统的发展，直觉会成为一种不可靠的指引。感觉缓慢、不稳定或出现故障的地方往往不是真正的问题所在。
在许多 Adobe Commerce 实施中，决策是根据假设、猜想的性能瓶颈、对结账问题原因的猜测或感知的集成问题做出的。这些假设通常会导致团队优化错误的领域，增加不必要的复杂性，或引入新的风险。
系统证据提供了不同的基础：
- 观察到的故障率，而不是假设的稳定性
- 实际客户行为，而不是道听途说的反馈
证据来自日志、量度、跟踪、队列深度、错误率和业务信号，如转化率下降或订单失败。当架构决策以此类数据为指导时，更改就变得有针对性且经得起推敲。
在 Adobe Commerce 系统中，由于存在多个领域和集成的交互，基于证据的决策可帮助团队专注于真正的限制因素，而不是症状。这有助于减少不必要的更改，缩短恢复时间，并增强人们对架构演进的信心。
选择以系统证据而非直觉为依据，将故障排除转变为分析，将架构设计转变为有意为之的实践。
让可观察性引领架构更改
如果问题未出现在日志、量度或跟踪记录中，那么您不是在解决根本原因，而是在猜测。
关键要点
- 将复杂性视为设计考虑因素，而不是实施的副作用。
- 在扩展团队或基础架构之前，先投资于架构能力。
- 让故障可见、可操作且可恢复。
- 利用有意的背压设计保护核心客户流程。