订单系统重构:一个"订单"对象膨胀到了 3000 行 我们老订单系统里有个 Order 类,承载了下单、改地址、退款、发票、物流查询……所有逻辑,文件 3000 多行,改一处怕动全身。重构时我用 DDD 的聚合(Aggregate)思想重新切分,核心问题其实就一个:聚合边界划在哪。划错了,要么事务跨
对账发现:账户余额和流水对不上 3 分钱 做交易系统最怕"状态对不上"。我们有个积分账户服务,某天对账脚本报:用户 A 的余额是 1200,但流水累加只有 1199.97。差 3 分钱,谁也说不清是哪笔操作漏了。传统的"改余额 + 插流水"两条写,因为中途异常出现过不一致。痛定思痛,我把核心域改成了
一次资损:限领 1 张的券,用户领了 2 张 1 月初的一个上午,运营在群里 @ 我:一张"新客专享 50 元券",配置的是每人限领 1 张,有用户领到了 2 张,已经核销了一张。 我查了数据库: mysql> SELECT user_id, coupon_id, count(*) c FROM c