电商系统架构总览怎么搭？一次讲清商品、库存、订单、支付、履约、营销的整体边界
大家好，我是一名有 4 年工作经验的 Java 后端开发。
前面我已经围绕高并发、电商后台、订单、库存、支付、权限、状态机、风控、搜索、推荐等主题持续写了很多篇。
这篇作为一个阶段性的收尾，我想从整体架构视角，把电商系统最核心的模块边界和链路关系做一次系统梳理。
🦅个人主页
🐼
文章目录
- 电商系统架构总览怎么搭？一次讲清商品、库存、订单、支付、履约、营销的整体边界
-
- 一、为什么电商系统最怕"模块都写了，但边界不清"
- 二、电商系统最核心的几个域
- 三、这些模块分别最核心的职责是什么
-
- [3.1 商品中心](#3.1 商品中心)
- [3.2 价格中心](#3.2 价格中心)
- [3.3 库存中心](#3.3 库存中心)
- [3.4 订单中心](#3.4 订单中心)
- [3.5 支付中心](#3.5 支付中心)
- [3.6 履约中心](#3.6 履约中心)
- [3.7 售后中心](#3.7 售后中心)
- [3.8 营销中心](#3.8 营销中心)
- 四、最重要的链路关系
- 五、最容易做乱的几个地方
-
- [5.1 商品、价格、营销混在一起](#5.1 商品、价格、营销混在一起)
- [5.2 库存和订单强耦合](#5.2 库存和订单强耦合)
- [5.3 支付逻辑直接写进订单服务](#5.3 支付逻辑直接写进订单服务)
- [5.4 履约状态和订单状态不分](#5.4 履约状态和订单状态不分)
- [5.5 售后和退款混成一个表](#5.5 售后和退款混成一个表)
- 六、面试中怎么回答
- 七、总结
- 八、结尾
一、为什么电商系统最怕"模块都写了，但边界不清"
很多项目一开始搭系统，通常是按需求一点点加：
- 要商品就加商品模块
- 要下单就加订单模块
- 要发货就加库存和物流
- 要做活动再加营销
这样短期没问题，但后面最容易出现这些情况：
- 订单和库存强耦合
- 商品和价格规则混在一起
- 支付逻辑塞进订单服务
- 履约和订单状态揉成一坨
- 营销规则散落在各服务
所以电商系统真正难的不是"模块有没有"，而是：
核心域边界有没有先想清楚。
二、电商系统最核心的几个域
我更建议至少拆成这些核心域：
- 商品中心
- 价格中心
- 库存中心
- 购物车
- 订单中心
- 支付中心
- 履约中心
- 售后中心
- 营销中心
- 用户 / 会员中心
如果是平台型电商，再加：
- 商家中心
- 平台审核与结算中心
三、这些模块分别最核心的职责是什么
3.1 商品中心
负责：
- SPU / SKU
- 类目
- 属性
- 上下架
3.2 价格中心
负责：
- 原价
- 售价
- 活动价
- 价格快照
3.3 库存中心
负责：
- 可用库存
- 冻结库存
- 已售库存
- 库存流水
3.4 订单中心
负责：
- 交易快照
- 订单状态
- 订单明细
- 操作日志
3.5 支付中心
负责：
- 支付单
- 回调
- 对账
- 补单
3.6 履约中心
负责：
- 配仓
- 发货单
- 物流轨迹
3.7 售后中心
负责：
- 售后申请
- 退款状态
- 审核流程
3.8 营销中心
负责：
- 活动
- 优惠券
- 促销规则
四、最重要的链路关系
一条典型下单链路大概是这样：
text
商品 -> 价格 -> 购物车 -> 下单 -> 库存冻结 -> 支付 -> 订单流转 -> 履约发货 -> 售后退款而且这条链路里每一环都不是孤立的：
- 商品和价格相关
- 价格和营销相关
- 下单和库存相关
- 订单和支付相关
- 支付和履约相关
- 售后和退款相关
所以设计的关键不是把模块分开，而是：
分清每个模块只负责什么，不要把所有能力都塞到订单中心里。
五、最容易做乱的几个地方
5.1 商品、价格、营销混在一起
会导致价格口径非常乱。
5.2 库存和订单强耦合
后面履约和补偿会很难拆。
5.3 支付逻辑直接写进订单服务
后面回调、对账、补单都会越来越乱。
5.4 履约状态和订单状态不分
多次发货、部分发货会很难做。
5.5 售后和退款混成一个表
业务原因和资金动作很难拆清。
六、面试中怎么回答
如果面试官问你：
电商系统整体架构一般怎么拆？
你可以这样回答：
第一，我会优先从领域边界去拆，而不是从页面功能去拆。电商系统最核心的几个域通常包括商品、价格、库存、购物车、订单、支付、履约、售后和营销，它们分别负责不同的业务语义。
第二，我特别关注的是边界清晰，比如商品中心管理商品主数据，价格中心管理价格规则和快照，库存中心管理库存账本，订单中心管理交易主链路，支付中心负责资金过程，履约中心负责发货和物流，售后中心负责退款和逆向链路。
第三，真正设计时我不会追求一开始就完全微服务化，而是先把领域边界想清楚，哪怕先以模块化单体落地，也比一开始就把边界做乱更稳。
七、总结
电商系统真正难的，不是模块多，而是：
- 模块边界是否清楚
- 状态和职责是否分层
- 链路是否能串起来又不过度耦合
如果只记一句结论，我觉得可以记住这句：
电商架构最怕的不是系统大，而是边界模糊；真正稳的设计一定是"模块职责清楚、链路关系明确、核心状态分层管理"。
八、结尾
如果你觉得这篇文章对你有帮助，欢迎点赞、收藏、关注。
这一阶段我把高并发、电商后台、状态机、权限、订单、库存、支付、履约、售后、营销、架构这些主题系统性地梳理了一遍，也欢迎大家继续交流更细的落地问题。