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

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

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

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

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

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

这篇文章我们来讨论基于本地和Redis实现的二级缓存公共组件，它的定位很明确：在一次 cache-aside 读请求中，先查当前进程的 L1，再查 Redis L2，最后才调用业务 loader。组件同时处理了 TTL、并发回源、空结果、批量漏键、主动失效和指标，但没有把自己包装成一个完整的分布式缓存一致性系统。

前面几篇文章分别拆过网关、会员、商品、订单和管理端。如果只从单个服务的角度看，系统像是一组相互独立的 CRUD；但用户真正经历的是一条连续链路：注册或登录，浏览商品，加购，下单，支付，等待积分和成长值到账，查看投放卡片，等待发货和物流，确认收货，最后可能进入售后或开票。

这一篇进入整条链路上最重的一段——订单与交易域：从确认单、下单、支付、发货、收货，一直走到售后与发票。

第 01 篇拆了业务全景，第 02 篇讲了技术选型与整体分层，第 03 篇走到了所有 C 端请求的入口——网关。这一篇继续往里走一步，进入网关背后的五个领域服务：会员、商品、营销、购物车、搜索，看每个域里「模型长什么样、流程按什么规则走、请求在其中如何流转」。