SaaS 电商设计 (二) 全链路解决方案概述和核心业务流程梳理

一.业务目标&技术目标

业务目标:完成多业态,多渠道的数字化运营
自有业务: O2O,B2C,B2B2C,S2B2b
平台业务:POPB2c,POPB2b,POPS2B2b

1.1 自有业务

O2O:全称Online to Offline.泛指的线上线下的业务融合.这种的情况分为两种情况,第一种通过线上的数字化运营引导线上用户线下消费;第二种通过线下的运营推广,引导用户线上消费.我们常见的比较多就是美团外卖.淘票票等.我们通过线上的APP进行外卖点单,电影院线上购票.线下进行外卖自提或者配送.电影票核销等.
第二种情况我们并不多见,能想到的就是我们往年见的比较多的地推.通过线下运营广告推广,用户进行扫码线上购物消费.

O2O的相比之前我们纯线下门店的购买行为,最大的特点我理解是可以利用目前可见的一些数字化运营方式提供用户更为精准的运营和营销.这是线下门店线下行为难以做到的原因.还有一点是O2O的模式客户拓展相比之前线下的夫妻老婆店,流量相对来说更能够突破地域的限制.

B2C:全称（Business-to-Customer）电商模式是指企业直接面向消费者销售产品或服务的电子商务模式。相比之前的传统模式,企业能够通过线上的数字化平台快速的将商品面向消费者,解决传统销售链路中的中间商(供应商,分销商,代理商等等)的过多问题.这样在整个销售链路缩短整体的供应链环节,能够以更有吸引力的销售价格吸引用户.同样在O2O的模式过程中的数字化能力也会在B2C的模式中得到体现.

常见模式举例:天猫是中国的一个B2C电商平台，其中的非自营的店铺商家消费者可以通过支付宝等电子支付方式，在天猫上购买商品，并通过快递配送收到商品。这里的非自营店铺商家在这里充当就是Business的角色.

B2B2C:全称为 (Business-to-Business-to-Customer) 指的是企业通过与其他小型的企业进行合作,通过分销,代理,夫妻老婆店等零售模式来将产品推向消费者.这里相比上面的B2C模式,在整个产品供应链的环节中间插入了小B的企业.那这种模式对于产品的直接生产商大B来说产品的对接客户目标从原有的广泛的 toC 客户变成了小B 企业,整个对接的成本在某种意义上成本降低,效率提升.

常见模式举例:拼多多是一家典型的B2B2C电商平台，平台通过与供应商合作，提供低价商品给消费者。它通过社交分享和团购模式吸引消费者，并与供应商合作提供优质产品。

S2B2B:全称为(Supplier-to-Business-to-Business) 指的是供应商（Supplier）与中间商（Broker）之间的电商模式。这里的中间商 (Broker) 常见的比如华北区域总代理 (first-level-businsess) ,天津总代理 (second-level-business) 。

以上是项目SaaS商城中的自有业务,最大的特点就是以上的业务开展都是围绕着一个业务主体来进行开展,所有的商户商家都是通过入驻的模式来进行toB,toC的业务销售.系统的模式上主要是 SaaS 的服务支持为主.但也不排除会有私有化的场景.

1.2 平台业务

在介绍整个平台具体类型之前,有比较先了解平台业务和上面自有业务最大的区别.自有业务平台业务最大的区别在于可以支持客户平台级别的业务场景.这么说可能有一些抽象.举一个具体的例子自有业务相当于京东商城,商城可以支持自营业务同时也支持三方商家入驻.但这些业务基于都是一个平台来处理.不会有商家要求进驻京东商城后完成一个另一个平台的能力(具备商家三方入驻,自营业务).

POP :全称为(Platform to Open ) 指的是平台开放计划,系统通过开放入驻的形式开放 c 商户入驻来开展c用户或者b用户销售. 销售的模式和上面相同.

1.3 技术系统目标

系统交付目标:通过一套代码支持 SaaS 版本部署与私有化交付.
架构目标:抽离领域能力与SOA.

二.客户场景

客户目标:完成私有化建设能力,且支持 SaaS 化场景产品接入

二技术目标

三.整体架构图

3.1 业务功能示意图

在这里插入图片描述

整个 SaaS 商城的解决方案面向的客户群主体是 SaaS 场景的客户.

3.2 代码服务调用示意图总述

在这里插入图片描述

总述
使用 soa RPC 网关的形式透出 RPC 服务.如: soa-C,soa-B,soa-E,soa-PB 均为 war 包形式.内部的服务将通过子包的形式来进行聚合为war包,通过tomcat容器进行部署,最后统一交为 Spring 容器管理管控.
在整个示意图的底部为整个解决方案系统所依赖的领域服务,是在整个产品迭代过程中逐渐被沉淀的领域资产,尽可能去遵循细粒度,原子化的原则去迭代.保证在产品交付过程中尽可能通过领域的原子化接口的编排和聚合做到不同的产品交付.所以这一层是尽可能的稳定且慎重的去增加接口服务,尽可能的标准化能力才会在这一层去落地.
soa © ,soa (B) ,soa (E) ,soa (PB) 到底是什么?
如 soa © [soa (B) ,soa (E) ,soa (PB) 均为独立的代码仓库, package 后的形式为 war .整体的仓库代码用以维护整个项目 RPC 服务透出,消费;整个入口应用的日志打印;子包服务引用;代码不是很多.其他模块的结构也同理如下.示例代码具体结构如下:
门店/库存/商品 soa submodule 是什么?
代码维护角度:首先他也是一个独立的代码仓库,它的维护原则是跟随产品来去建的.实际开发过程中如:商品-soa-B,商品 soa-C 均在这个代码仓库中维护.只是不同的 module 来维护.独立 module 开发后,通过私服来管理打包发布为jar包的形式.最后通过公共的 soa-C,soa-B 网关来集成.具体结构如下:

在商品的 soa 中通过不同的产品线约定了 price-b ,product-b ,product-pb,product-c 的 module. 最后通过rc-app-ka-product-x-service 打包后的 jar 包完成集成.

哪些代码被放在 soa 层:首先它是在领域之上的利用领域服务或者领域服务编排交叉后的结果去交付的产品功能,或者是目前暂时不可以被沉淀的领域能力的业务代码.如商详属于商品模块,但是从整个服务流程上来讲商详内部调用了很多领域服务 (门店,库存,优惠卷,履约等) 并不属于商品模块.那么有同学又说了这也可以放在商品模块来做,不错确实可以通过基础设施层来做到二方服务的接口形式做到.但是接下来这个问题.在整个交付过程中不同的产品决定了商详的特定场景还是会跟着产品来走,例如: B2c,B2b 不同产品的商详是不同展示的.如果都通过基础领域服务的形式来开发,不可避免的会在底座的领域服务造成很多直接面向产品的代码,难以做到一套通用能力去交付每个产品,也增加了维护成本.如下则是我们最终在公共网关引入的 service jar 包.

 <dependency>
     <groupId>com.x.rc.app.ka.product</groupId>
     <artifactId>rc-app-ka-product-c-service</artifactId>
     <version>2.1.0-pre-SNAPSHOT</version>
</dependency>

门店/库存/商品 core module 是什么?
首先这些 core module 代码是独立的仓库.在整个迭代过程中可以被标准化能力的代码沉淀.也就是我们常见在DDD开发过程中被提到的领域资产.这些代码维护我理解要遵循几个原则
- 原子化
  
  尽可能细粒度的服务化
- 领域边界内聚
  
  较少的去依赖三方,甚至二方接口.如果有尽量通过接口或者技术设施层来做到解耦
- 脱离技术实现细节
保证在领域服务开发中不会对技术实现产生依赖或者尽可能的少依赖.如* cache,mq* 等技术细节应该做到对实现不依赖,保证是在适配不同云产商产品对接过程中做到无缝切换.对于框架的依赖,这里个人觉得没必要做到完全解耦,比如说对于 spring 的依赖,对于 mybatis 的依赖,这些耳熟能详,基本覆盖**90%**的使用人群框架再去做到解耦,很可能会在成本控制上一去不复返.难以做到实际开发成本和效率的结合.如下具体商品仓库模式: