【商品架构day10】一个商品系统的需求有哪些 - 从产品层面说起

本文来自大宋嘟嘟的分享。从产品层面来说，商品系统是电商中台的核心之一，商品中心统一管理商品。商品中心的数据应用场景也非常多，从前端来说，所有展示给用户的关于商品的信息，均为商品中心所提供，比如商详，订单，营销，等提供所有的数据支撑，从后端来说，商品中心为订单，仓库管理，供应商管理，渠道管理，采购管理，财务管理等提供基础数据支撑。

 

一.商品系统层次设计

   随着商业模式的变化，商品中心的信息架构也会有调整，例如，B2C，B2B，C2C，C2M，O2O等等多种商业模式，或者是融合的商业模式。所以，原来的单个实体商品，也会分为实物商品，虚拟商品，比如，电影票，火车票，兑换券，服务券，跑腿单等等，商品的多样性已经远远超越的具体的实物，所以伴随着商品系统，也有涉及的不同，但是商品系统的意义和作用我们已知，找到其核心的业务流程和支撑服务，产出最适合自己平台的解决方案。我们这里仅用实物电商作为例子来讨论。

 

二.商品系统架构设计

  这里我们会将商品中心信息架构分为九个部分：类目管理，属性管理，品牌管理，商品管理，包装管理，标签管理，导入记录管理，操作日志管理，商品评论管理。

 

三.规划和思考

  对于整个商品中心比较核心的功能，我们需要进行以下的规划和思考。

1.类目模块规划

  类目分为前台类目和后台类目。前台类目，前台类目是为用户查找商品所设置的展示功能，运营可根据运营需求灵活调整前台类目，用户通过前台类目查找相应的商品时，自动从后台类目中检索相应的商品。目前电商均为重中台，轻前台，当电商中台支持多个前端时，会有相应的运营需求，多个前端展示不同的前台类目，前台类目可以设置不同的展示渠道。而且，在整个电商平台中，入驻的商家也可以自定义自己的前台类目。如下图：

2.属性模块规划

我们在设计商品属性时，可以针对后台类目，可以添加不同的属性集，在属性集里可以建立不同的属性。如下图所示：

 

 

3.关于品牌模块规划

  对于品牌，我们可以让搜索商品时，在不同的维度去搜索，增加了检索的便捷性，对于以后的用户画像，用户偏好，搜索推荐等等，都会提供支撑服务。

 

4.关于商品本身基础信息规划

  商品在流转与整个交易流程中，它应当包含的信息如下。我们在整个交易的过程中会调用商品的各种字段，如下这些信息是基本可以满足多个系统调用的基本信息。

 

5.关于商品快照功能

  当一个商品在线上交易，我们需要完善其各种基础层信息，并提供平台其他系统支撑服务，当此商品停产，或者不再销售，我们可以做商品下架处理，但是此商品之前的交易信息，都留在我们整个系统的数据中心，如果我们进行追溯和调用，我们需要保存上平当时的部分信息。作为电商交易中的对象，对其任何的改动都至关重要，所以存储快照一方面是把每次的更改记录都保存下来。另一方面是存在类似于交易订单的场景，需要当时商品的信息，以便处理投诉、维权。商品快照的数据较大，因为每一次的改动都会生成一份数据，所以不能存在数据库，通常进行外部存储。查询的时候需要商品id和快照版本进行查询。

6.商品销量统计

  值得注意的是，我们在搜索引擎中排序商品时，经常会用到按照销量排序，但销量其实不是作为商品本身的一个属性，因为销量是根据交易订单成交量来动态计算出来的，但是一般电商网站都会有根据销量排序的需求，那这个怎么实现呢？肯定是搜索引擎来做，因为搜索条件太多，排序条件太多，数据库索引也支持不了各种组合查询、排序。所以我们就根据业务需求，一般销量一天统计一次就满足需求了。在商品索引中添加一个销量字段，每天定时任务从订单里面统计销量，然后再以消息的方式，推送到搜索引擎，搜索排序的时候搜索引擎就能帮我们实现这个功能。

 

四.总结

  这里我们思考了商品系统分层设计，以及每一层对应的功能和功能设计。我们也讨论了如果我们做一个商品系统，会设计九大模块。针对于这些架构，我们规划了几个比较重要的模块，以及他们应该所包含的基本功能，还有他们与其他功能的关系。经过了这些思考，我们可以着手做我们的商品中心了。

 

---

=>更多文章请参考：《中国互联网业务研发体系架构指南》

https://blog.csdn.net/Ture010Love/article/details/104381157

=>更多行业权威架构案例、领域标准及技术趋势请关注微信公众号 '软件真理与光'：

更多权威内容关注公众号：软件真理与光