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

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

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

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

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