用途：可组合商务是一种基于 MACH 原则（微服务、API 优先、云原生、无头）的电商架构方法，每个商务能力（购物车、目录、搜索、CMS、结账、忠诚度）由最佳服务提供，而非单体平台。服务通过 API 与事件通信，团队可替换或升级单个能力而不影响系统其余部分。
适用场景：单体平台（Magento、Salesforce CC）无法随团队或流量扩展时；不同领域（目录、结账、忠诚度）发布节奏与归属不同时；需要混合最佳供应商（如 Algolia 搜索、Contentful CMS、commercetools 商务）时；进入需要不同履约、定价或税务供应商的新市场时；需从单一后端支持多店面（Web、移动、门店、B2B 门户）时。
主要能力与用法：围绕商务能力设计服务边界，每个服务拥有自己的数据并仅通过 API 暴露，服务间不共享数据库；实现 BFF（Backend-for-Frontend）聚合多个上游 API，可用 GraphQL schema stitching 或 federation 暴露；用事件驱动架构协调跨服务流程（下单→预留库存→触发履约→发邮件）；用 Saga 模式与补偿事务处理分布式事务；用加法式版本策略与 Tolerant Reader 模式管理 API 版本与向后兼容；用断路器（如 opossum）防止级联故障。
前置条件：Node.js 18+（或适配后端语言）、PostgreSQL（或关系数据库）、搜索服务（Algolia、Elasticsearch 或 Typesense）、Stripe 账户与 API 密钥、邮件服务（SendGrid、AWS SES 或 Postmark）。示例使用 TypeScript/Node.js，可适配任意技术栈。Shopify Hydrogen、WooCommerce REST API/WPGraphQL、Magento GraphQL/PWA Studio 均可作为 MACH 栈中的后端。
最佳实践与限制：明确数据所有权，每份数据只有一个记录系统；为最终一致性设计；用 API 网关处理认证、限流、日志与 SSL；用 OpenTelemetry 实现分布式追踪；为事件加 schemaVersion；用服务网格处理服务间流量；建议从模块化单体开始，仅在团队边界与运维成熟时再拆分为微服务。常见陷阱包括分布式事务失败导致数据不一致、关键路径延迟叠加、API 契约破坏下游消费者、共享数据库造成隐藏耦合、跨多服务调试困难。相关技能包括 @commerce-api-gateway、@saleor-development、@shopify-hydrogen、@webhook-architecture、@flash-sale-scaling、@edge-commerce。