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

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

祝好!

2020/2/14

 

1、问题及挑战

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

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

 

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

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

 

2、核心思路与解法

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

 

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

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

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

在实施的过程中,主要的战略如下:

 

3、具体方案及分拆

主要解决方案分成领域模型、应用架构两块。

领域模型强烈依赖对业务的理解和抽象,我们经历了从模仿到创造两个过程。领域模型要做的好,有两点:一是从业务和技术上了解行业TOP公司怎么做的,背后的目的是为了认清业务的发展方向,开拓技术视野。二是立足部门具体业务,多和业务方做沟通,了解他们的产品规划。商品系统核心的核心在于数据,在于数据实体的职责、实体和实体之间的关系。在领域模型上,我们构建了价格子模型、库存子模型、spu模型、服务单元模型,还有我们的标签、类目、品牌、相册等周边模型。

 

系统的核心用例

 

与其它主要实体的关系

 

领域模型的演进之路

具体的领域模型演进过程如下:

2015/1:仿淘宝从0到1快速支持业务

背景:
2015年到店综合玩乐BU(旧)开展新交易形式的一些探索,包括门票预订、ktv预订、ktv点单等。当时bg没有一套低层商品系统作支撑,考虑后续的通用性、从淘宝京东“copy”了一套商品系统。

变更目标:
支撑玩乐BU新交易形式快速探索

变更策略:
搭建商品两层领域模型:Product商品、SKU

 

2017/5:构建服务行业的商品模型

背景
2017年商品组织中台化,支撑丽人美甲款式、通用预订等业务。需求挑战在2个方面:
1) 预订类的预订,跟场地、时间等要素相关性较大。传统的SKU模型已经没有办法支撑这类需求。
2)类目扩增迅速,类目不同、导致商品模型结构差异较大。系统需要高效、统一地管理这些模型,譬如合法性校验等。
3)为了提升行业信息的标准化,提升上单效率、优化搜索及信息展示。行业运营有强烈的信息标准化管理诉求。

目标
1) 独立库价模型,灵活扩展库价模式
2) 建立元数据模型,高效扩展类目
3) 建立SPU、打造到综多类目的行业标准


策略
1)独立库价子域,拆分库价子系统。跟据不同的库价类型、抽象对应的库价管理模式。
2)搭建商品系统的元模型,描述商品模型,在之上搭建元数据的应用场景。譬如:合法性校验、动态表单等。
3)搭建SPU信息标准化模型,沉淀行业库。支撑美甲、家装、爱车等。

 

2017/10:构建服务单元

背景
1)团购为了满足套餐信息的提高信息质量、优化c端展示,联合泛商品做服务单元的结构化方案。
2)足疗需要复用服务单元,上层再录入预订、团购等商品。

目标
为了满足商品更细粒度的信息结构化,如套餐包含的“SPA”、“水光针”等,需要一个服务单元模型做载体、在商家维度做复用。

策略
搭建服务单元:Goods,在商家维度跨交易形式复用。

 

2018/3:上单配置化效率

背景
到综诸多类目商品模型的字段差异很大,导致上单页每次开发耗时较久。因此我们启动了上单配置化(动态表单)的项目,以便解决上单页效率的问题。

目标
配置前端上单模板,建设快速搭建上单能力。

策略
上单配置化:扩展前端模板、数据集等元数据模型。

 

2018/8:商品静态信息分拆

背景
到综目前很多交易形式,团购、预付、预订、拼团等。商品散在各个独立的产品做管理,商品信息不互通,很多业务方有做多交易形式的诉求。

目标
希望构建统一的商品内容库,信息复用、快速发布到各交易形式。

策略
静态商品信息独立化

 

应用架构的演进之路

应用架构主要包含:逻辑架构、部署架构、技术架构。技术架构完全复用公司的基础中间件。我们的逻辑架构,经历了从四层到五层的变迁,分为:数据层、基础服务层、通用逻辑层、业务逻辑层、展示层。我们比经典的四层架构、多出来一个通用逻辑层,因为基础服务层的职责是维护领域模型、不涉及业务逻辑,我们有很多的业务有共性的逻辑,因此我们多了一层、用来沉淀通用业务逻辑。在垂直划分上,基础服务层,按领域模型划分;其他业务层按照业务场景划分,譬如商家端、用户端。

具体的应用架构演进过程如下:

2015/1:B/C端分离

背景

快速支持新业务MVP探索。

 

2016/1 :服务化分层

 

2017/1:元数据驱动的商品系统

 

开发及物理架构的演进之路

在物理部署架构上,我们的两个原则是:避免大的b、c端场景物理耦合,避免AP与CP场景物理耦合;另一方面也注意避免因为物理部署拆得过细,导致系统过高的开发与维护复杂度,或降低了机器的复用率。

 

逻辑架构的演进之路

基础模型层:从数据的视角来审视。没有逻辑域的视角,譬如:供给、信息、B端上单、C端查询等。承担数据增删改增的功能。
通用逻辑层(通用逻辑层):分功能场景,承担通用核心UseCase的职责。
业务逻辑层:专用业务逻辑,业务间做解耦、不相互影响。

 

4、结果及收益

通过沉淀领域模型、分层抽象系统能力,泛商品支撑了100+业务类型。

商品系统接入在线门店15万,接入在线商品250w,接入在线sku 500w,涉及到综所有BU相关业务。

今天商品soa方式接入1day人力支持联调和配置。商品从生产到消费的主要链路环节,都已实施配置化。

 

关于短期规划。我们在领域模型上,我们将把商品的静态信息、独立出内容模型,做统一上单。在应用架构上,我们将实施彻底的微服务化,按领域拆分得更细,尤其在数据库、应用集群等物理部署架构范围内。在技术方向上,我们完善元数据、推动商品全链路的配置化一切,提高研发效率。除了技术中台,我们也将配合业务中台,去沉淀更多的一些通用产品,采取以扩类目的方式、从产品级给bu赋能。

 

发布了179 篇原创文章 · 获赞 379 · 访问量 17万+
展开阅读全文

没有更多推荐了,返回首页

©️2019 CSDN 皮肤主题: 技术工厂 设计师: CSDN官方博客

分享到微信朋友圈

×

扫一扫,手机浏览