• 【20220912】电商业务的核心流程


    时间:2022年09月12日

    作者:小蒋聊技术

    邮箱:wei_wei10@163.com

    【20220912】电商业务的核心流程——音频版https://www.ximalaya.com/keji/51588599/568636568

    大家好,欢迎来到小蒋聊技术。小蒋准备和大家一起聊聊技术的那些事。

    小蒋最近在深入学习电商这个行业的业务和它的软件系统之间的内在联系,电商在最近的10年也是快速发展壮大,在这么多年的系统建设和运维过程中也总结了很多最佳实践,小蒋将会在学习的过程中,持续的为大家分享。

    概念

    咱们先来了解一下概念:

    • 问:什么是电商系统的核心流程?
    • 答:电商系统的核心流程就是,那些不太会变化的流程,也可以简单理解为主流程。

    • 问:为什么要先定义核心流程?
    • 答:因为在需求还不太明确的情况下,要定义那些不太会变化的核心流程,先把这些核心流程搭建出来,尽量简单地实现出一个最小化的系统,然后再逐步迭代完善。

    • 问:定义核心流程不是产品经理的事儿嘛?和架构师有什么关系?
    • 答:架构师要在有限的资源情况下,保证产品方案和技术方案落地。核心流程就是系统的最小范围。所以,不考虑资源和需求范围的架构师,技术就算再厉害方案最后都很难落地。

    需求分析在大厂,一般是由产品经理来承担的。大部分情况下,核心流程的定义是产品经理、业务负责人、架构师和技术共同定义的。但是,在小公司,往往核心流程的定义会落在开发身上。

    小蒋不分享需求分析的方法和理论,这个产品经理比我懂。小蒋我只分享一个关键的点:技术同学,不要一上来就设计功能和定义方法,而是先要尝试回答下面两个问题:

    1. 这个系统(或者是功能)是给谁用的?
    2. 这些人使用这个系统(或者是功能)来解决什么问题?

    电商业务,小蒋认为在这个每天都用手机购物的时代,每个人都很熟悉,很容易回答这两个问题。这两个问题的答案,我把他称为业务需求。

    这个系统(或者是功能)是给谁用的?

    买东西的人,我们叫用户。卖东西的人,我们叫运营人员。还有谁会用这个系统?老板 啊!技术同学得记住,你在设计任何一个系统的时候,千万不要把领导或者老板给忘了,他们是给你钱的人,他们的意见非常重要!

    这些人使用这个系统(或者功能)来解决什么问题呢?

    • 用户用系统来买东西;
    • 运营用系统来卖东西;
    • 老板在系统中了解他赚了多少钱;

    这两个问题的答案就是业务需求,咱们可以用下面这个Use Case图来清晰的表述:

    用户、运营人员、老板在Use Case 中叫参与者,那为什么要识别参与者呢?

    咱们站在商家的视角来分析:

    • 电商系统的用户,肯定希望是越多越好。用户越多,根据转换率,订单就会越多,销售额就会越大。
    • 电商系统的运营人员,肯定是希望越少越好。请运营人员是需要花成本的,需要的运营人员越少肯定成本就越低。

    咱们切换一下视角,站在架构师的视角再来分析:

    • 根据需求,电商系统的用户,未来肯定是海量级别的或者是互联网级别的。从技术上需要考虑高可用和高并发,以及存储容量。
    • 电商系统的运营人员,如果是企业商城,运营人员应该是有限级别的或者是企业级别的。从技术难度上来说,不会像互联网级别那么高。如果是淘宝或者天猫这种电商平台,商家入驻的模式。那运营人员就是互联网级别了。但,它的增量速度肯定不会有用户这么快。从架构上来看,也是需要分别对待的。

    识别参与者,是为了了解系统参与者的数量级和未来增量的情况。根据参与者的数量级别,采用互联网应用架构还是企业级应用架构。电商系统之所以要拆分模块或者子系统,就是因为需求不同,所以功能对系统的性能指标和架构要求都不一样。如果功能都写在一起,最后的结果技术同学可想而知。

    做业务需求的主要目的,是理解清楚业务场景。这对我们技术同学来说十分重要,因为这些场景决定了我们的功能模块究竟该设计成什么样子才合适。

    核心业务流程

    电商系统的核心业务流程,肯定是 购物这个流程。小蒋分享一下经典的流程图:

    在上面这个图中我们可以看到,这是一个电商购物的流程。电商系统,一般都是这样一个流程。

    流程从用户选购商品开始,用户先从你的 App 中浏览商品;找到心仪的商品之后,把商品添加到购物车里面;都选好了之后,打开购物车,下一个订单;下单结算之后,就可以支付了;支付成功后,运营人员接下来会给每个已经支付的订单发货;邮寄商品给用户之后,用户确认收货,到这里一个完整的购物流程就结束了。

    那我们通过时序图(Sequence Diagram)再来看看,对象之间是怎么交互的。

    1. 用户开始浏览商品,需要有一个 商品模块 来支撑,给用户展示商品的介绍、价格等等这些信息。
    2. 用户把选好的商品加入购物车,这个步骤,也需要一个 购物车模块 来维护用户购物车中的商品。
    3. 用户下单肯定需要一个 订单模块 来创建这个新订单。订单创建好了之后,需要把订单中的商品从购物车中删除掉。
    4. 订单创建完成后,需要引导用户付款,也就是发起支付流程,这里需要有一个 支付模块 来实现支付功能,用户成功完成支付之后,需要把订单的状态变更为 「已支付」。
    5. 之后运营人员就可以发货了,在系统中,发货这个步骤,需要扣减对应商品的库存数量,这个功能需要 库存模块 来实现,发货完成后,还需要把订单状态变更为「已发货」。
    6. 最后,用户收货之后,在系统中确认收货,系统把订单状态变更为「已收货」,流程结束。

    这个流程涉及到的功能模块有:商品、购物车、订单、支付和库存, 这几个模块就是一个电商系统中的核心功能模块。

    这只是其中一个 购物 流程,还有其他的流程,如:运营人员进货、老板查看报表等没有覆盖到。

    其他功能的分析也是如此,就不一一做分析了,直接给出电商系统的功能模块划分:

    整个系统按照功能,划分为十个模块,除了购物流程中涉及到的:商品、订单、购物车、支付、库存五个模块以外,还补充了促销、用户、账户、搜索推荐和报表这几个模块,这些都是构建一个电商系统必不可少的功能。小蒋来简单介绍一下每个模块需要实现的功能。

    • 商品:维护和展示商品信息和价格。

    • 订单:维护订单信息和订单状态,计算订单金额。

    • 购物车:维护用户购物车中的商品。

    • 支付:负责与系统内外部的支付渠道对接,实现支付功能。

    • 库存:维护商品的库存数量和库存信息。

    • 促销:制定促销规则,计算促销优惠。

    • 用户:维护系统的用户信息

    *注意用户模块它是一个业务模块,一般不负责用户登录和认证,这是两个完全不同的功能。

    • 账户:负责维护用户的账户余额。

    • 搜索推荐:负责商城中,搜索商品和各种列表页和促销页的组织和展示

    简单的说就是决定让用户优先看到哪些商品。

    • 报表:实现统计和分析功能,生成报表,给老板来做经营分析和决策使用。

    特别说一下,促销模块 是电商系统中,最复杂的一个模块。各种优惠卷、满减、返现等促销规则,都非常复杂。再进行叠加,小蒋举个例子,最开始的时候京东内部的业务促销定制人员甚至都搞不清楚 叠加后的促销会变成什么样子,被薅羊毛的事件也是频有发生。后来,增加了 风控模块 这个情况才有所好转。

    在创建订单时,订单模块 把商品和价格信息 传给促销模块促销模块返回 一个可以使用的 促销列表,用户选择好促销和优惠,订单模块把商品、价格、促销优惠这些信息,再次传给促销模块,促销模块则返回促销价格。

    至此,一个电商系统的概要设计就结束了。

    系统架构策略

    在需求不明确情况下,系统设计往往需要靠预判。但是预判都是有概率的,不可能每次都对,甚至能有6成概率正确,就已经是大师级水平了。策略的作用就是让我们在对的时候,能够多实现一点,而错的时候能少修改一点,不断通过多做少修改,提高胜率。

    小蒋还是比较强调策略的。判断这个东西,理解个思路就好,策略才是提高胜率的东西。

    如果你是商城系统的设计者,小蒋建议把促销的变化和复杂性封禁在促销模块内部。不能让一个促销模块把整个电商系统都搞得非常复杂,一定要根据企业现阶段的业务情况,去设计和实现。一个设计方案,必须考虑方案的可行性和可落地性。

    互联网系统的另外一个策略就是 小步快跑 通过不断地小版本的迭代,不停地进行商业可行性的验证。这个阶段,不要过多的考虑性能问题。只有商业模式可行性通过后,也就是系统可以稳定的赚钱了,才会扩大推广。所以,商业模式稳定后,才要开始考虑系统的性能问题,也就是所谓的高可用、高并发、系统容量、技术架构等等问题。小步快跑能够有效的控制投入。就好比你一下子开发了一个大系统,用的时候才发现根本就不是那么回事,系统要满足现实业务,需要重构。俗话说“步子迈大了,容易拉胯”,这是一个道理。

    这就是策略的作用,未来小蒋将会和大家一起完善我们的架构策略。

    思考

    小蒋带着大家,咱们一起了解了电商系统的概要设计,那么接下来咱们一起来思考一个问题,如果让你自己设计一个电商系统,你会如何考虑。

    咱们做产品的同学需要思考一下:

    1. 商城系统中的会有哪些角色?
    2. 核心业务流程是什么?
    3. 需要划分成几个模块?为什么?

    咱们做技术同学需要思考一下:

    1. 使用那些技术栈?分别解决业务中哪个场景的问题?
    2. 需要哪些第三方的框架和云服务?
    3. 我们的存储系统该怎么选型?

    这些问题,小蒋将会在后面的分享中,继续与大家交流的。

    年龄的增长不可怕,可怕的是从未成长!

    感谢大家支持小蒋,小蒋希望和大家共同成长,谢谢。

  • 相关阅读:
    spring整合Mybatis-P23,24,25
    2.27数据结构
    3分钟搭建自己的MQTT服务器,就是这么简单!
    用Python实现创建十二星座数据分析图表
    关于react与vue的一些对比
    高可用架构的设计方法
    一些常见的Windows命令
    C++ 哈希桶模拟实现(补充)
    ModelX一款开源的机器学习模型管理仓库
    BOM操作——window对象(一)
  • 原文地址:https://blog.csdn.net/wei_wei10/article/details/126820143