最佳的集成计划并不是一份 API 列表，而是一份共享描述，说明应该发生什么、哪个系统负责、数据应多久传输一次以及当数据未按预期传输时团队应如何处理。
从运营结果开始
在讨论端点或中间件之前，应以通俗易懂的语言编写目标工作流程。例如：完成的商店销售应减少正确的库存池、记录匹配的付款、在获得同意的情况下更新客户资料，并将所需的参考信息提交给财务以便进行对账。
这为运营、财务、电子商务和技术团队创建了一个共同可测试的结果。
为每个关键记录选择一个真实来源
决定产品、价格、库存、客户、订单和付款参考信息的主控位置。当两个系统可以编辑相同记录而没有明确规则时，集成往往会加剧不一致性。
有用的决策：
对于每个数据对象，记录其记录系统、允许编辑者、更新方向、预期延迟和恢复方法。
映射跨系统边界的事件。
涵盖常规和边缘事件：销售完成、退款发放、订单取消、库存接收、商品转移、客户合并、付款撤销和结算接收。为每个事件提供一个持久标识符，以便团队能够在连接平台之间追踪。
- 定义哪个事件启动工作流程。
- 保留原始订单和支付参考信息。
- 确保重试安全，以免同一事件被重复发布。
- 记录状态变化以便支持和审计。
在上线前设计恢复路径
连接可能会失败，凭证可能会过期，数据有时会以意外的形式到达。生产就绪的设计会对可恢复事件进行排队，隔离无效记录，并向具有足够上下文的相关负责人发出警报以便采取行动。
对于多门店零售商，回退方案还应说明门店是否可以继续离线交易，以及排队交易如何在稍后进行对账。
测试业务场景，而不仅仅是连接
技术连通性证明系统能够互相通信。验收测试证明完整工作流能够运行。围绕真实交易场景构建测试用例，并在每个下游系统中确认结果。
- 完成并退还正常销售。
- 在支持的情况下使用多种支付和分期付款。
- 在各地点之间调拨和退还库存。
- 应用忠诚度积分获取和兑换规则。
- 对账订单、支付和结算。
最终的检查清单应列出每个测试的负责人以及签署所需的证据。