This article from the Song toot share . From the product perspective, the system is one of the core commodity electricity supplier in Taiwan, Commodities Center unified management of goods. Data center scenarios goods is also very much, from the front, all displayed to the user information on our products, both trade centers provide, such as business details, orders, marketing, and other support to provide all the data from the back end , the commodities Center for the order, warehouse management, supplier management, channel management, procurement management, financial management, to provide basic data support.
A commodity system level design
With the change in business models, information architecture Commodities Center will have to adjust, for example, B2C, B2B, C2C, C2M, O2O so a variety of business models, or is the integration of the business model. So, the original single physical goods, will be divided into physical goods, virtual goods, such as movie tickets, train tickets, vouchers, voucher, run errands, etc. single, diversity of goods has gone far beyond the specific physical, so along with the commodity system, there are different involved, but the meaning and role of commodity systems known to us, to find its core business processes and support services, output most suited to their platform solutions. We are here only as an example of physical electricity business to discuss.
II. Trade system architecture design
Here we will trade information center architecture is divided into nine sections: category management, property management, brand management, product management, packaging management, labeling management, import records management, operation log management, product reviews management.
III. Planning and thinking
For more central function of the entire commodity center, we need the following planning and thinking.
1. Category planning module
Category is divided into front and back-end category categories. Front-end category, front-end category is set by the user to find goods for display function, the operator can automatically retrieve the appropriate product from the back-end category according to operational needs flexibility to adjust when the front-end category, you find the appropriate goods by front-end category . At present electricity supplier in Taiwan are both heavy and light reception, when the electricity supplier in Taiwan supports multiple front ends, there will be a corresponding operational needs, different front-end category of multiple front-end display, front-end category can set different display channels. Moreover, the entire electronic business platform, the settled merchants can also customize your own front-end category. As shown below:
2. Properties planning module
We designed the product attributes, can target back-end categories, you can add a different set of attributes, you can create different properties in the Property episode. As shown below:
3.关于品牌模块规划
对于品牌，我们可以让搜索商品时，在不同的维度去搜索，增加了检索的便捷性，对于以后的用户画像，用户偏好，搜索推荐等等，都会提供支撑服务。
4.关于商品本身基础信息规划
商品在流转与整个交易流程中，它应当包含的信息如下。我们在整个交易的过程中会调用商品的各种字段，如下这些信息是基本可以满足多个系统调用的基本信息。
5.关于商品快照功能
当一个商品在线上交易，我们需要完善其各种基础层信息，并提供平台其他系统支撑服务，当此商品停产，或者不再销售，我们可以做商品下架处理，但是此商品之前的交易信息，都留在我们整个系统的数据中心，如果我们进行追溯和调用，我们需要保存上平当时的部分信息。作为电商交易中的对象，对其任何的改动都至关重要，所以存储快照一方面是把每次的更改记录都保存下来。另一方面是存在类似于交易订单的场景，需要当时商品的信息，以便处理投诉、维权。商品快照的数据较大，因为每一次的改动都会生成一份数据，所以不能存在数据库，通常进行外部存储。查询的时候需要商品id和快照版本进行查询。
6.商品销量统计
值得注意的是，我们在搜索引擎中排序商品时，经常会用到按照销量排序，但销量其实不是作为商品本身的一个属性，因为销量是根据交易订单成交量来动态计算出来的，但是一般电商网站都会有根据销量排序的需求，那这个怎么实现呢？肯定是搜索引擎来做，因为搜索条件太多，排序条件太多，数据库索引也支持不了各种组合查询、排序。所以我们就根据业务需求，一般销量一天统计一次就满足需求了。在商品索引中添加一个销量字段，每天定时任务从订单里面统计销量，然后再以消息的方式，推送到搜索引擎，搜索排序的时候搜索引擎就能帮我们实现这个功能。
四.总结
这里我们思考了商品系统分层设计，以及每一层对应的功能和功能设计。我们也讨论了如果我们做一个商品系统，会设计九大模块。针对于这些架构，我们规划了几个比较重要的模块，以及他们应该所包含的基本功能，还有他们与其他功能的关系。经过了这些思考，我们可以着手做我们的商品中心了。
=>更多文章请参考：《中国互联网业务研发体系架构指南》
https://blog.csdn.net/Ture010Love/article/details/104381157
=>更多行业权威架构案例、领域标准及技术趋势请关注微信公众号 '软件真理与光'：
