电商系统架构总览怎么搭？一次讲清商品、库存、订单、支付、履约、营销的整体边界

电商系统架构总览怎么搭？一次讲清商品、库存、订单、支付、履约、营销的整体边界

大家好，我是一名有 4 年工作经验的 Java 后端开发。
前面我已经围绕高并发、电商后台、订单、库存、支付、权限、状态机、风控、搜索、推荐等主题持续写了很多篇。
这篇作为一个阶段性的收尾，我想从整体架构视角，把电商系统最核心的模块边界和链路关系做一次系统梳理。

🦅个人主页
🐼

一、为什么电商系统最怕“模块都写了，但边界不清”

很多项目一开始搭系统，通常是按需求一点点加：

• 要商品就加商品模块
• 要下单就加订单模块
• 要发货就加库存和物流
• 要做活动再加营销

这样短期没问题，但后面最容易出现这些情况：

• 订单和库存强耦合
• 商品和价格规则混在一起
• 支付逻辑塞进订单服务
• 履约和订单状态揉成一坨
• 营销规则散落在各服务

所以电商系统真正难的不是“模块有没有”，而是：

核心域边界有没有先想清楚。

二、电商系统最核心的几个域

我更建议至少拆成这些核心域：

• 商品中心
• 价格中心
• 库存中心
• 购物车
• 订单中心
• 支付中心
• 履约中心
• 售后中心
• 营销中心
• 用户 / 会员中心

如果是平台型电商，再加：

• 商家中心
• 平台审核与结算中心

三、这些模块分别最核心的职责是什么

3.1 商品中心

负责：

• SPU / SKU
• 类目
• 属性
• 上下架

3.2 价格中心

负责：

• 原价
• 售价
• 活动价
• 价格快照

3.3 库存中心

负责：

• 可用库存
• 冻结库存
• 已售库存
• 库存流水

3.4 订单中心

负责：

• 交易快照
• 订单状态
• 订单明细
• 操作日志

3.5 支付中心

负责：

• 支付单
• 回调
• 对账
• 补单

3.6 履约中心

负责：

• 配仓
• 发货单
• 物流轨迹

3.7 售后中心

负责：

• 售后申请
• 退款状态
• 审核流程

3.8 营销中心

负责：

• 活动
• 优惠券
• 促销规则

四、最重要的链路关系

一条典型下单链路大概是这样：

商品 -> 价格 -> 购物车 -> 下单 -> 库存冻结 -> 支付 -> 订单流转 -> 履约发货 -> 售后退款

而且这条链路里每一环都不是孤立的：

• 商品和价格相关
• 价格和营销相关
• 下单和库存相关
• 订单和支付相关
• 支付和履约相关
• 售后和退款相关

所以设计的关键不是把模块分开，而是：

分清每个模块只负责什么，不要把所有能力都塞到订单中心里。

五、最容易做乱的几个地方

5.1 商品、价格、营销混在一起

会导致价格口径非常乱。

5.2 库存和订单强耦合

后面履约和补偿会很难拆。

5.3 支付逻辑直接写进订单服务

后面回调、对账、补单都会越来越乱。

5.4 履约状态和订单状态不分

多次发货、部分发货会很难做。

5.5 售后和退款混成一个表

业务原因和资金动作很难拆清。

六、面试中怎么回答

如果面试官问你：

电商系统整体架构一般怎么拆？

你可以这样回答：

第一，我会优先从领域边界去拆，而不是从页面功能去拆。电商系统最核心的几个域通常包括商品、价格、库存、购物车、订单、支付、履约、售后和营销，它们分别负责不同的业务语义。

第二，我特别关注的是边界清晰，比如商品中心管理商品主数据，价格中心管理价格规则和快照，库存中心管理库存账本，订单中心管理交易主链路，支付中心负责资金过程，履约中心负责发货和物流，售后中心负责退款和逆向链路。

第三，真正设计时我不会追求一开始就完全微服务化，而是先把领域边界想清楚，哪怕先以模块化单体落地，也比一开始就把边界做乱更稳。

七、总结

电商系统真正难的，不是模块多，而是：

• 模块边界是否清楚
• 状态和职责是否分层
• 链路是否能串起来又不过度耦合

如果只记一句结论，我觉得可以记住这句：

电商架构最怕的不是系统大，而是边界模糊；真正稳的设计一定是“模块职责清楚、链路关系明确、核心状态分层管理”。

八、结尾

如果你觉得这篇文章对你有帮助，欢迎点赞、收藏、关注。
这一阶段我把高并发、电商后台、状态机、权限、订单、库存、支付、履约、售后、营销、架构这些主题系统性地梳理了一遍，也欢迎大家继续交流更细的落地问题。