【商品架构day1】O2O行业怎么做商品系统——与一手带大的系统说句再见

没有完全做总结，大家有想法的可以私下交流。人还是有感情的，亲自建起来的系统就像孩子一样，孩子长大了、父母老了、总要告别。人于系统、公司也一样。

祝好！

2020/2/14

 

1、问题及挑战

阶段一：单bu多类目。2015年，到店综合没有一个商品系统，只有一套团购套餐系统。玩乐BU，需要做一些新交易形式的探索，类目又特别多，譬如门票预订、KTV预订、点单等。

这对商品系统提出两个挑战：一是如何高效的支撑这些多类目形式；二是怎么让这些多类目可扩展。

 

阶段二：多bu多类目。从2016年开始，到店综合的很多bu，开始做很多新交易形式的探索，面临着跟我们类似的问题。因此我们的商品系统，决定平台化开放出去、让各bu快速开发。

由此产生几个挑战。一是我们如何面对不同的业务方产品的个性化诉求。二是我们如何高效支撑业务方不同层次的系统需求。

 

2、核心思路与解法

阶段一的核心思路与解法。因为没有可以复用的系统，所以我们决定造一个可扩展的轮子，以便复用系统、提高研发效率，这是技术天然会做的一个选择。因为公司没有很好的一个系统可以借鉴，所以我们了解业内做得好的TOP公司，主要参照亚马逊、淘宝和京东。对于第一个挑战，我们通过调研和分析，再结产品的业务规划，决定构建商品和sku的两层模型，用“类目决定属性”的原则构建我们系统的可扩展性。在实现上，最小化了很多相关的模型及功能，譬如类目树、元数据等；但同时保证底层的商品系统，从领域模型到系统服务都较为通用。对于第二个挑战，这里从领域模型到服务的划分，最大的一个边界是通用逻辑和业务逻辑保解耦；第二个大边界，是商品的管理和线上应用解耦。

 

阶段二的核心思路与方法。当我们面多BU多类目不同的产品形态的诉求，发现：由于本地生活是一个大的非标行业、类目不同，对商品的诉求也不同。电商的sku模型没有办法很好的支撑到这些诉求。拿ktv预订举例，ktv的价格和库存跟时间、包型强相关，按照sku模型的销售属性决定sku的定义、那实现的复杂度多几倍。

因此对于第一个挑战，我们的一个方法论是通过一个个不同业务方的需求，抽象和沉淀到领域模型之中，形成到店综合商品领域的通用业务解决方案。

对于第二个挑战，业务方有的基础服务上接入，而有的则希望在流程层、聚合层或展示层接入。这要求平台有不同层次能力的支撑，以便提高业务方的一个接入效率。我们的做法，是以clean架构方法论为指导，结合我们系统的实际、采用简单性原则，将应用系统分成五层，水平划分定义每一层解决的问题、垂直划分隔解耦不同的逻辑功能。

在实施的过程中，主要的战略如下：