一、基础介绍
执行域包括两个核心一是订单的产生,二是订单的履约。往往品牌商既有自营渠道(包括2c、2b)、又有第三方渠道。那么有两种设计思路:
-
把第三方渠道的订单当作自有渠道的订单产生一种特殊方式,开放订单创建接口,并统一履约。
-
好处:简单,在3方渠道不多、且自有渠道单一,并且逻辑相识时系统结构会简单
-
坏处:
-
当3方渠道的履约方式、库存分配方式、逆向逻辑等有差异时,会让自有渠道参杂很多不相干的逻辑引入不必要的复杂度
-
自有渠道不够独立和纯粹,自有渠道多样化时难以支撑
-
-
-
把商家自营渠道假设为特殊的第三方渠道,再建立统一的订单管理系统来对接渠道订单,并完成履约
-
好处:交易与履约逻辑分离,对未来发展有扩展性
-
坏处:引入一定复杂度
-
我们采用的是第二套方案,整体结构简易图如下
二、模型介绍
核心设计逻辑
-
首先我们看到上图交易域和履约域有很多相同父模型的子模型,交易域和履约域的父模型在CDM的在himalaya-trade里。履约域看oms(libra)对himalaya-trade扩展,交易域看b2c(leo)和b2b(aries)对对himalaya-trade扩展。libra、leo、aries是我们对上层业务产品的命名,取自黄道十二星座
-
交易域是多商家平台视角设计,有自身渠道必要的履约相关信息,完成自闭环。
-
履约域是从单一商家对接多渠道视角设计,有渠道交易订单同步后完成履约发货相关设计,完成自闭环。
-
履约域的合单拆单发货设计,渠道订单只能合单为履约单不可拆,履约单可以拆单发货不可合。用m2o和o2m的组合设计来降低难度,而非采用两个m2m的设计。
Oinone社区 作者:史, 昂原创文章,如若转载,请注明出处:https://doc.oinone.top/oio4/9323.html
访问Oinone官网:https://www.oinone.top获取数式Oinone低代码应用平台体验