现在国内的电商产品真的是多如牛毛,功能其实都大同小异,质量参差不齐。有的当软件产品卖,有的依托在完整的SaaS平台中卖服务,百家齐放。

我司本身有运营着一个B2C的电商系统,基于国外一个开源电商项目二次开发而来,修修改改也使用了将近三年了,今年公司打算对其进行重构(基本上是推倒重来),并进一步将其产品化。之所以有这种想法,也是因为我们调研了一圈市面上的产品后,觉得这个市场还是有机会的。

我之前少有接触过此类项目,现在的电商系统早不再是简单的产品展示+在线支付的粗犷派,其中充斥着各种营销各种活动,应该说是及其复杂。本文简单的罗列出这段时间来我们团队梳理出的一些需求难点,供大家思考和讨论。

订单编辑

订单应该是电商系统中的核心业务,几乎所有角色都会“与其有染”。教科书式的订单的简单模型是:

  • 下单用户
  • 购买的商品
  • 支付方式
  • 物流方式及收货地址
  • 订单状态(待支付,已支付,已发货,已完成,已取消)

通常会包含这些基本的属性。但真实世界会更加黑暗和复杂,比方说下面这些属性:

  • 使用的积分数
  • 使用的优惠券
  • 物流拆分(如常温与冷冻)

这些都会导致订单价格计算的时候引入复杂逻辑。当然,模型一旦确定,搞就完事儿了,不服就干嘛~

实际开发中,我们得到的宝贵结论(教训)是:订单编辑才是万恶之首。
我们参考了一些电商项目,它们提供订单编辑的操作往往都是在订单未付款的状态下。一旦用户付款就锁定订单不允许编辑了。

但其实,即便是未付款状态,订单编辑依然是很复杂的,考虑的情况非常的繁杂,下面我举一些例子:

  • 编辑后优惠券条件不满足
  • 编辑后影响积分使用条件
  • 物流成本和方式变更

此外,还存在订单编辑带来的安全问题,账目核对问题等。尤其是在用户已经支付后再编辑订单的时候,一切就更加的邪恶。
参考主流的电商平台,一般也都是让用户取消当前订单并再次下单。

其实上述问题不光涉及到开发复杂性,商户在使用的时候也很难完全理解每一种情况。而下单用户呢?多数下单用户发现订单被编辑了,我相信一定还是会感到不安,即便是已经线下和商户协商好了,这种协商往往很灵活(各种突发奇想的操作),或者很“死板”(直接退单再下)。

针对已付款的订单进行编辑,从金额角度会有三种情况:价格不变,变低,变高。前两种好办,可以不麻烦下单用户就完成,而价格变高就必须让用户补差价了,之前很多电商平台中的商户都会创建一个虚拟商品专门用来补差价。

总结来说就是,由于导致订单编辑的原因和编辑波及的方面太多,无法轻易收敛,所以目前建议放弃模式匹配的思维。
可能提供“松散”的策略会更易于开发和使用:

可以在此思路上继续往走下去。

营销活动

只有你想不到,没有做不到的营销,水深的很。我们看一下有赞电商后台提供的营销类型:

简直是眼花缭乱,试问谁能抵抗这么多类型的诱惑完成荷包保卫战?你们先聊,我去下单了~

这些营销活动,最终都会直接影响购物流程,甚至改变购物流程。要想让系统能够轻松扩展出各种影响活动,对系统的扩展性就要提出很高的要求才行。

这些活动中,有些是独立入口,有些则辅佐在主流程的某些步骤中,有些只是逻辑扩展,有些会涉及到页面展示。这就要求系统在页面渲染和计算流程中处处提供扩展点。这些扩展点有些是同步执行,有些可以异步调用。
针对各种场景,我们可以在扩展点处提供Hook,或事件消息机制,尽可能让这些营销活动模块化插件化。

另外一方面,商户新建一个营销活动,除了规则和玩法以外,还需要设置该活动的范围,这里所说的范围,分为:

  • 商品维度范围
  • 用户维度范围
  • 时间维度范围

各种维度的交集才是有效范围。在电商系统中展示商品时,要动态计算出该商品所处于哪个活动范围也是一个不小的问题。解决这类问题,需要前后端配合,单一方的优化总感觉不够完美。

例如,我们系统的首页,加载商品数据后,异步加载活动规则,前端计算出商品和活动的匹配关系。又或者在活动创建时强绑定和商品的关系,在商品CURD时维护这种关系。

在时间维度方面,可以借助定时任务触发活动上线和下线时机。具体怎么做,还是根据具体情况来决策。

最后想说的是,涉及到抢购的那种活动比较危险,有条件的话应该隔离部署这些活动,并做抢购相关的优化。关于抢购可以在GG上搜到大量的技术方案分享。

页面布局自定义

回顾我个人的上网经验,最早看到这种功能还是在QQ空间,后来很多不同类型的网站也都提供此类功能,主要是因为我们人类关于个性的追求。
在电商系统中,常见的页面布局主要是首页,首页又分成pc端和mobile端。这种自定义,可简单可复杂,开发成本较高。
我不确定业界都是怎么实现的,个人感觉借助现代前端框架组件化方案,再设计一种简单的DSL来序列化存储用户的配置,应该是一个完整的解决方案。

总之,直觉告诉我,这一块感觉坑不浅。

SEO

之前看过一篇文章,好像是18年年底的,主要是讲google目前的爬虫是否能识别js代码。结论是google对外宣称这一点的时候,用了“maybe”,实际测试虽然比较理想,但官网却不提供任何保证。更何况其它搜索引擎呢?所以就目前来看,SEO还是需要考虑的!

所以,在选择前端技术的时候,要多考虑SSR(Server-side Render),一般主流框架都有完善的SSR方案。