电商系统类图怎么画？商品订单会员关系一文讲清

在设计电商系统时，商品、订单与会员三大模型的关系最容易画乱。梳理不清，会导致数据库冗余、接口难改、扩展功能成本高。围绕一个典型电商场景，可以通过类图示例把电商系统核心领域模型结构化表达，帮助产品、架构师和后端工程师在设计、重构、写文档和准备面试时有一套可参考的思路。

电商核心领域怎么划分更清晰？

电商系统的领域划分越清晰，类图越容易稳定下来。通常会把核心对象分为三块：商品相关（商品、类目、价格）、交易相关（购物车、订单、支付、配送）和用户相关（会员、账户、权益）。很多人一开始只画一个大“订单”包含全部信息，导致订单对象承担过多职责，扩展任何新功能都要改动核心类。

在划分时，推荐先按业务流程划区：浏览商品阶段只涉及商品模型；下单结算阶段引入订单、优惠、库存扣减；支付完成后才出现发货、售后等对象。用“在哪个业务阶段出现，就归属哪个子领域”的规则来收口类图，比单纯按数据库表来画更贴近业务和面向对象分析。

商品模型类图怎么设计更易扩展？

商品模型建议区分“商品信息”和“销售信息”两个层次。实践中可以用 Spu 表示标准商品单元（标题、详情、品牌、类目），用 Sku 表示可售单品（规格、条码、库存、销售价格）。Spu 与 Sku 是一对多关系，价格、库存等经常变化的字段尽量放在 Sku 层，避免频繁更新商品基础信息表。

在类图上，ProductCategory 与 Spu 也是一对多，Brand 与 Spu 一对多，形成一棵可复用的商品树。需要做多图、多属性时，可以抽出 ProductAttribute、ProductImage 等附属类，通过聚合关系挂在 Spu 或 Sku 上。这类拆分能让商品模型在引入新维度（如积分价、渠道价）时，只需扩展附属类而不破坏核心结构。

订单模型类图如何拆分才不臃肿？

在订单模型中，最关键的一点是区分订单头与订单行。类图里通常有 Order 和 OrderItem 两个类：Order 负责订单级信息（订单号、会员、状态、总金额），OrderItem 负责具体购买的商品 Sku、数量、单价、小计金额，两者是一对多关系。任何与具体商品行相关的逻辑，尽量放在 OrderItem 上而不是堆在 Order 上。

支付与订单的关系也值得单独建模。Payment 通常与 Order 是一对多或多对多（通过中间表）关系，以支持合单支付、拆单支付场景。物流相关可以抽出 Shipment、ShipmentItem，与 Order、OrderItem 形成关联。通过“头-行-扩展信息”的结构，让订单模型既能承载复杂业务，又保持核心对象职责单一。

会员模型如何与商品、订单关联？

会员模型是电商系统的业务锚点。类图里通常以 Member 为核心，关联账户信息、等级、积分等扩展类，例如 MemberLevel、MemberPointAccount。Member 与 Order 是一对多关系，表示一个会员可以产生多个订单。任何与用户画像、生命周期相关的字段尽量放在会员侧，而不是散落在订单或商品模型中。

与商品的关系多通过行为记录来体现。类图中可以有 BrowseHistory、Favorite、CartItem 等类，分别关联 Member 与 Spu 或 Sku。这样既能支持个性化推荐，也能支撑运营分析。当引入会员等级折扣、专属价等功能时，可以在商品价格相关类里增加与 MemberLevel 的关联，而不用直接改动 Member 本身，减少耦合。

会员、订单、商品之间的关系如何在类图中表达？

在完整类图里，一条订单会同时关联会员与多个商品 Sku：Order 通过外键关联 Member，OrderItem 通过外键关联 Sku，Sku 再关联到 Spu 与 Category。这样既能从会员维度查订单，也能反向从商品维度分析销量。类图中的方向通常从拥有者指向被拥有者，但业务分析时要习惯从不同视角遍历。

优惠相关对象会把三者进一步串起来。常见设计是 Promotion 或 Coupon 与 Member、Order、Sku 建立多对多或条件关联，例如某类优惠只对指定会员等级、指定类目商品生效。这一层关系可以通过中间类（如 PromotionScope、CouponUsage）解耦表达，避免在核心三类对象上堆积过多判断条件字段。

如何在现有类图上扩展新功能更稳妥？

扩展功能时的优先策略是“新增类，而不是给核心类狂加字段”。例如引入会员等级，只需增加 MemberLevel 类，并在 Member 中加一个等级引用；订单计算会员折扣时，读取等级规则即可，不必在订单类里写死复杂逻辑。这种做法能让类图随业务增长而“长枝条”，而不是不停给树干扩粗。

订单拆分、合并场景也类似，可以通过 ParentOrder、ChildOrder 或 OrderRelation 等类来表达上下级关系，而不是让单个订单类承担全部逻辑。引入优惠、积分抵扣时，可抽出 OrderDiscount、OrderPointUsage 等扩展类。通过保持核心类稳定、用外围扩展类承载变化，可以显著降低电商系统重构成本。

常见问题

电商类图设计一定要区分 Spu 和 Sku 吗？

是否区分取决于业务复杂度和未来规划。单一商品、无规格的小体量项目，可以只用一个商品类，早期实现会更简单。计划支持多规格、不同价格、库存管理、渠道价的场景，提前引入 Spu/Sku 分层能减少后续大规模数据迁移的风险。在类图上预留结构比事后拆表、重构代码更安全。

订单模型中是否需要单独建支付类？

在有退款、分期、多支付方式、合单支付等场景时，抽出独立的 Payment 类几乎是必选项。它可以承载支付渠道、交易号、支付状态、金额等信息，与订单保持清晰的一对多或多对多关系。若直接把支付字段塞进订单类，会导致订单状态与支付状态混杂，逻辑变得难以维护，也不利于对账与风控。

会员等级、积分等功能放在一个类里好吗？

很多项目一开始习惯做一个“大会员表”，什么字段都往里放。更合理的做法是让 Member 只承担“身份识别与基础信息”的角色，等级、积分、优惠券账户分别抽成独立类，通过一对一或一对多关系关联。这样每块权益规则可以独立演进、重构，既减轻核心会员类压力，也利于团队分工。

画类图时与数据库表结构必须一一对应吗？

类图更关注领域概念与对象职责，表结构更关注存储与查询效率，两者不必完全一一对应。一个类可以映射到多张表，一个表也可以支撑多个类的读取视图。在建模阶段先把“概念边界”和“关系方向”画清楚，再在实现阶段做适当的表合并或拆分，能兼顾业务可读性与性能需求。