这一篇文章我们来介绍这个项目的重要角色：管理后台。它既不是 C 端商城的另一个页面，也不是订单服务的简单管理界面，而是一套面向运营人员的 B 端系统。

用户积分看起来像会员表上的两个数字：integration 和 growth。但只要系统同时支持每日奖励、订单抵扣、支付后奖励、退款返还、积分过期和会员升级，这两个数字就不再是普通字段，而是一个需要并发控制、幂等和审计的账户系统。

这篇文章梳理一下项目中用到的设计模式.

前面的文章已经从业务和链路角度介绍过 B 端管理后台。这一篇文章我们来看看一个后台管理的请求，究竟如何从 Gin 路由走到 Service、Repository、DAO 和具体的 MySQL 实例；订单状态消息如何进入后台并按版本收敛；物流策略、秒杀填充和物流同步又分别由谁负责。

这一篇主要解决一个问题：如果第三方服务迟早可能更换，代码应该把“可替换”放在哪里？

前面几篇文章已经把订单域、网关和端到端消息链路拆开了。支付是其中最容易被“一个支付接口”掩盖复杂度的部分：订单服务既要生成收银台或二维码，又要接收浏览器回跳和支付平台通知；支付结果还可能在回调、用户刷新、前端轮询之间重复到达。

这篇主要梳理项目中的异步任务：主请求先把必须完成的事实写下来，积分、投影、自动收货、超时关单和售后处理再沿着 MQ 或定时任务继续推进。

支付成功以后，商城通常还要做一件“看起来很轻”的事：根据订单和会员画像，挑几张营销卡片展示在支付成功页。

这一篇我们讲讲：消息队列客户端到底应该依赖什么。

这篇文章我们来讲讲订单状态的两个问题：