购物车服务边界别和订单服务搅在一起

很多电商系统初期都会把购物车当成“订单的前半段”，这样做短期很快，但项目一复杂就容易出问题。购物车本质上服务的是选购过程，订单服务的是成交结果，这两个对象关注点本来就不一样。

我更倾向把购物车单独做成服务边界。Feathers 提供 cart service，负责增删改查和当前用户态；订单服务只在提交时读取购物车快照并生成订单项。这样促销试算、库存预占、商品下架这些变化，就不会直接把订单逻辑拖得满地分支。

如果两个边界混在一起，最常见的问题就是：用户改了购物车，已生成订单也跟着受影响；或者订单失败后购物车状态被污染，用户得重新选一遍。把购物车当成临时意图，把订单当成正式交易，这条线一旦立住，后面的补偿逻辑会清楚很多。

服务边界收得越清楚，系统越容易演进。购物车和订单虽然紧挨着，但绝不应该是同一个概念。

电商链路里最怕的是边界看起来清楚，状态其实在串味

「购物车服务边界别和订单服务搅在一起」这种问题在电商系统里几乎都会反复出现，因为订单、购物车、支付、搜索这些模块在业务上彼此相关，但在数据职责上又必须保持克制。前期如果为了开发快而把查询、状态流和补偿动作揉在一起，后面最先受伤的通常不是单个接口，而是排障和补单流程。

落地时优先守住的线

• 先定义谁拥有状态迁移，谁只消费结果，别让多个服务都觉得自己可以改同一份关键状态。
• 把幂等键、事件表和补偿动作放在入口附近，避免重复回调或重复消息把下游一起带乱。
• 搜索、筛选和列表接口优先服务真实业务路径，而不是为了复用表结构把所有能力硬塞进一条查询。