完整规则
任务说明
邮件、支付、存储和AI供应商以后都可能换,我计划先把业务逻辑与供应商SDK隔离。但我不想为“可能替换”做过度架构,需要接单者结合真实替换经历告诉我接口留到什么程度才划算。 目标不是做得全面,而是让我少走弯路。请比较一次成功和一次失败的供应商替换经历或公开案例,指出哪些抽象真的降低成本、哪些只是提前制造复杂度。 请按实际决策顺序完成,而不是按知识目录排列: 1. 为邮件、短信、支付、对象存储和AI模型定义统一适配器接口。 2. 把供应商SDK和业务逻辑隔离。 3. 设计超时、重试、限流、幂等和统一错误模型。 4. 提供本地模拟实现以及切换供应商时需要修改的文件清单。 输出要求 交付适配器接口、错误模型和伪实现;第一页或第一屏必须能看到“现在先做什么、暂时别做什么、什么信号出现后再升级”。经验案例直接放在对应决策点下。 资料与经验怎么区分 不要向我索取项目资料。请先列出合理的默认假设,再基于接单者真实经验完成方案;经验与事实分开标注,无法确认的内容明确写成待核验项。 验收清单 1. 业务代码不依赖具体供应商SDK。 2. 重试与幂等边界清晰。 3. 提供本地模拟实现。 4. 至少有一项接单者根据经验主动删减或调整的常规做法,并解释原因。 排除项:不接入任何真实供应商账号。