作为零售SaaS的核心系统之一，商品系统的架构工作是相对重要的，好的商品架构系统可以为业务的稳定性、可拓展性提供支撑。那么商品系统的架构设计，应该如何进行？本篇文章里，作者对这一问题做了总结，一起来看看吧。

　　SaaS产品就像一座冰山，冰山以上的部分是功能、数据（可见部分）、用户界面，冰山以下是系统架构、完整的数据模型、开放体系、非功能性需求（扩展性、可维护性、性能、安全等）。

　　短期内想要快速上线产品，可能只需关注冰山以上的部分就够了，但是SaaS公司想要在市场上建立长期的竞争优势，比拼的一定是冰山以下的部分，并且在这块的投入绝对远超冰山以上的部分。

　　商品系统是零售SaaS最基础、最核心的系统之一。商品系统几乎需要支撑所有业务系统，例如C端商详、购物车、订单、履约、结算、售后、库存、供应链等，都需要依赖商品系统的能力。

　　为了保障业务的稳定性、可扩展性，必须要重视商品系统建设，否则，后续业务和系统将很快丧失扩展性和灵活性，甚至无法支撑业务发展，必须推倒重来，付出惨痛的代价才能挽回。

　　不同行业对商品管理的需求差异非常大，想要构建成熟稳定的商品系统，需要对各行业的商品管理需求，进行深度分析。只有这样，才能抽象出共性的规律和特征，保障业务建模的质量。列举一些行业差异性需求：

　　时尚服装：款式管理，配比、配码管理，商品季节性管理。3C数码：串码管理，配件管理，售后维修。美容护肤、医药保健：批号管理，生产日期与有效期管理，试用品管理。生鲜行业：生产日期与有效期管理 ，生鲜加工管理，称重商品与 PLU 码，辅助单位管理（管理重量和数量，例如：鱼，按照重量核算，以条作为辅助单位）。

　　商品系统作为最基础、最核心的系统之一，几乎所有业务系统，都需要依赖商品系统的能力。

　　从业务全流程来看，需要支撑采购、配送、销售、履约、退货、退仓、核算、结算、数据分析等各个业务环节。

　　从商品生命周期的管理来看，商品状态包括建档、新品、正常、淘汰、清理等，各个状态之间流转也异常复杂。

　　1）平台SPU

　　指的是标准化产品单元，是商品信息聚合的最小单位，是一组可复用、易检索的标准化信息的集合，该集合描述了一个产品的特性，又可称为平台商品。

　　SPU的概念来源于电商平台业务，第一个关键点在于，SPU模型会提取商品的共性属性用于信息检索，这些属性通常是能够快速识别商品，并且是消费者较为关心的属性。

　　第二个关键点在于，SPU的属性是全平台标准化的，这样才能有效保障消费者的检索体验与商家利益，例如，消费者搜索256G的iPhone12，有填写容量的商品能搜出来，没填容量的商品就搜不出，这显然不合理，因此平台需要规范所有商品的关键属性。

　　2）商品

　　特指商家的销售商品，一个商家可以有很多商品，若N个商家卖同一个商品，如iPhone13，该场景下有1个平台SPU实例，N个商品实例。每个商品可以有多个规格，例如大小、颜色、尺码等。

　　3）SKU

　　SKU（Stock Keeping Unit），指的是库存量单位，又称最小存货单位。以iPhone13为例，关键规格有颜色（黑色、红色、银色、金色）、容量（128G、256G、512G），可以组合出4×3=12个SKU。

　　实物商品：以有形实体存在，不能通过网络来传递，必须依赖传统的物流运输系统来传递。例如，鸡蛋、大米、手机等。服务商品：能够实现交易的无形商品，无需物流参与，就能完成交易，例如，话费充值等。组合商品：一般指人为将几个单独售卖的商品组合在一起，进行合并售卖的商品，例如：下午茶套餐、七夕美妆组合等。多规格商品：代表一组SKU的商品，消费者只能选中其中某一个SKU，例如，以iPhone13为例，关键规格有颜色（黑色、红色、银色、金色）、容量（128G、256G、512G），消费者选中了黑色128G的iPhone13进行下单交易。预售商品：一般来说，预售商品会提前销售，但实物还未生产，因此，预售商品不会录入实物库存，售出也不会扣减实物库存。预售商品由一组原材料加工而来，加工关系一般称作配方，因此，当预售商品扣减库存时，实际会扣减原材料的库存。

　　前台类目：前台类目是面向消费场景和用户视角的分类，根据运营需求，灵活多变，主要用于用户快速筛选。后台类目：后台类目是前台类目搭建的基础，后台类目主要面向商家运营，相对稳定，不会经常变更。品牌：品牌是比较特殊的商品属性，需要单独进行管理。品牌是人们对一个企业及其产品、售后服务、文化价值的一种评价和认知，是一种信任。

　　商品属性，又称为产品属性、商品参数，是产品本身固有的特征。不同行业的商品，差异性非常大，有很多行业差异化属性。根据使用目的、用途不同，商品演化出各式各样的属性，有的用于展示，有的用于分析，有的用于经营管控。

　　下面根据商品属性不同的分类法，逐一展开描述：

　　描述属性：商品货号、商品名称、商品?描述、规格、型号、产地、等级、生产厂商、商品图片等。统计属性：品牌、分类、系列、款式、适用人群、适用年龄等。考核属性：一般用于组织业绩考核，品牌、分类、系列等。物流属性：长、宽、高、净重、毛重、重量单位等。管控属性：是否季节商品、是否保险、是否支持配送、是否支持打折、是否保质期管控、是否串码管理等。销售渠道属性：不同的销售渠道会有一些特殊的属性，例如，美团、饿了么的最小购买数量、平台分类等。销售属性：也称为规格属性，该属性是组成SKU的特殊属性，直接影响到买家的购买和商家的库存管理，例如衣服的颜色、尺寸。

　　指导价：厂商给出的一个出售的参考价格。销售价：商家根据自己情况提高或降低指导价得到的最终销售价格。渠道价格：在分渠道售卖的时候，商品的基础销售价格。时间价格：不同的时间，可以有不同的价格。成本价：一般特指商品的单个成本，成本价会到sku维度。

　　商品库：零售企业操作和管理商品的总集。管理层级商品：管理层级需要操作和管理的商品的集合，管理层级有多种形态，例如区域、部门、分公司、子公司等。店铺商品：即门店、商城等店铺单元的商品集合。渠道商品：发布到某个销售渠道的商品集合，例如微信商城、美团外卖、饿了么外卖等渠道。

　　商品的生命周期状态：建档、新品、正常、预淘汰、淘汰、清理、待归档等。商品的经营状态：商品在各个业务阶段，可以有不同的状态，来控制业务的经营，例如，商品销售状态上架、下架。

　　1）展现层

　　直接与用户交互的层级，负责向用户显示信息，或解释用户命令。

　　2）应用层

　　应用层的服务对应一个具有业务价值的场景用例，主要负责对核心服务进行组合和编排，负责处理场景用例内的执行顺序以及结果的组装，通过API网关向展现层提供服务。

　　3）服务层

　　系统的核心层，负责表达业务概念、业务状态以及业务规则，包含了该领域（问题域）复杂的业务知识抽象和规则定义。该层难点在于领域对象分析上，例如实体，值对象，聚合（聚合根），领域服务，领域事件，仓储，工厂等方面的分析，成熟的领域逻辑不会有太大变化，所以服务层的业务逻辑通常是共性的、稳定的。

　　4）主数据平台

　　主数据是跨部门、业务系统，能够反映核心业务实体状态的核心基础信息。对于商品系统而言，商家信息、组织机构、员工权限、商品数据模型是该系统依赖的主数据。

　　在业务早期，主数据平台是非必须的，上层系统模块直接从DB中读取数据并应用即可，但随着系统逐步复杂后，多个团队对数据的改动会互相影响，不利于系统扩展，可用性也大大降低，因此，需要拆分出多个主数据服务，将核心数据的访问收拢在一起。

　　本文从商品系统的定位、挑战、概念模型、应用架构等方面，阐述了商品系统架构设计经验与方法，希望对读者有所帮助。

　　在SaaS模式下，商品技术架构也存在大量挑战，例如可用性问题、数据一致性、大流量访问、分店商品大批量处理、商品数据模型治理等，会在后续的文章中一一介绍。

　　本文由 @汤师爷 原创发布于人人都是产品经理。未经许可，禁止转载。

　　题图来自Unsplash，基于CC0协议。

　　该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。