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