时间：2022年09月12日
作者：小蒋聊技术
邮箱：wei_wei10@163.com
【20220912】电商业务的核心流程——音频版
用户、运营人员、老板在Use Case 中叫参与者，那为什么要识别参与者呢？
咱们站在商家的视角来分析：
- 电商系统的用户，肯定希望是越多越好。用户越多，根据转换率，订单就会越多，销售额就会越大。
- 电商系统的运营人员，肯定是希望越少越好。请运营人员是需要花成本的，需要的运营人员越少肯定成本就越低。
咱们切换一下视角，站在架构师的视角再来分析：
- 根据需求，电商系统的用户，未来肯定是海量级别的或者是互联网级别的。从技术上需要考虑高可用和高并发，以及存储容量。
- 电商系统的运营人员，如果是企业商城，运营人员应该是有限级别的或者是企业级别的。从技术难度上来说，不会像互联网级别那么高。如果是淘宝或者天猫这种电商平台，商家入驻的模式。那运营人员就是互联网级别了。但，它的增量速度肯定不会有用户这么快。从架构上来看，也是需要分别对待的。
识别参与者，是为了了解系统参与者的数量级和未来增量的情况。根据参与者的数量级别，采用互联网应用架构还是企业级应用架构。电商系统之所以要拆分模块或者子系统，就是因为需求不同，所以功能对系统的性能指标和架构要求都不一样。如果功能都写在一起，最后的结果技术同学可想而知。
做业务需求的主要目的，是理解清楚业务场景。这对我们技术同学来说十分重要，因为这些场景决定了我们的功能模块究竟该设计成什么样子才合适。
核心业务流程
电商系统的核心业务流程，肯定是 购物这个流程。小蒋分享一下经典的流程图：
在上面这个图中我们可以看到，这是一个电商购物的流程。电商系统，一般都是这样一个流程。
流程从用户选购商品开始，用户先从你的 App 中浏览商品；找到心仪的商品之后，把商品添加到购物车里面；都选好了之后，打开购物车，下一个订单；下单结算之后，就可以支付了；支付成功后，运营人员接下来会给每个已经支付的订单发货；邮寄商品给用户之后，用户确认收货，到这里一个完整的购物流程就结束了。
那我们通过时序图（Sequence Diagram）再来看看，对象之间是怎么交互的。
- 用户开始浏览商品，需要有一个 商品模块 来支撑，给用户展示商品的介绍、价格等等这些信息。
- 用户把选好的商品加入购物车，这个步骤，也需要一个 购物车模块 来维护用户购物车中的商品。
- 用户下单肯定需要一个 订单模块 来创建这个新订单。订单创建好了之后，需要把订单中的商品从购物车中删除掉。
- 订单创建完成后，需要引导用户付款，也就是发起支付流程，这里需要有一个 支付模块 来实现支付功能，用户成功完成支付之后，需要把订单的状态变更为 「已支付」。
- 之后运营人员就可以发货了，在系统中，发货这个步骤，需要扣减对应商品的库存数量，这个功能需要 库存模块 来实现，发货完成后，还需要把订单状态变更为「已发货」。
- 最后，用户收货之后，在系统中确认收货，系统把订单状态变更为「已收货」，流程结束。
这个流程涉及到的功能模块有：商品、购物车、订单、支付和库存， 这几个模块就是一个电商系统中的核心功能模块。
这只是其中一个 购物 流程，还有其他的流程，如：运营人员进货、老板查看报表等没有覆盖到。
其他功能的分析也是如此，就不一一做分析了，直接给出电商系统的功能模块划分:
整个系统按照功能，划分为十个模块，除了购物流程中涉及到的：商品、订单、购物车、支付、库存五个模块以外，还补充了促销、用户、账户、搜索推荐和报表这几个模块，这些都是构建一个电商系统必不可少的功能。小蒋来简单介绍一下每个模块需要实现的功能。
- 商品：维护和展示商品信息和价格。
- 订单：维护订单信息和订单状态，计算订单金额。
- 购物车：维护用户购物车中的商品。
- 支付：负责与系统内外部的支付渠道对接，实现支付功能。
- 库存：维护商品的库存数量和库存信息。
- 促销：制定促销规则，计算促销优惠。
- 用户：维护系统的用户信息
＊注意用户模块它是一个业务模块，一般不负责用户登录和认证，这是两个完全不同的功能。
- 账户：负责维护用户的账户余额。
- 搜索推荐：负责商城中，搜索商品和各种列表页和促销页的组织和展示
简单的说就是决定让用户优先看到哪些商品。
- 报表：实现统计和分析功能，生成报表，给老板来做经营分析和决策使用。
特别说一下，促销模块 是电商系统中，最复杂的一个模块。各种优惠卷、满减、返现等促销规则，都非常复杂。再进行叠加，小蒋举个例子，最开始的时候京东内部的业务促销定制人员甚至都搞不清楚 叠加后的促销会变成什么样子，被薅羊毛的事件也是频有发生。后来，增加了 风控模块 这个情况才有所好转。
在创建订单时，订单模块 把商品和价格信息 传给促销模块，促销模块返回 一个可以使用的 促销列表，用户选择好促销和优惠，订单模块把商品、价格、促销优惠这些信息，再次传给促销模块，促销模块则返回促销价格。
至此，一个电商系统的概要设计就结束了。
系统架构策略
在需求不明确情况下，系统设计往往需要靠预判。但是预判都是有概率的，不可能每次都对，甚至能有6成概率正确，就已经是大师级水平了。策略的作用就是让我们在对的时候，能够多实现一点，而错的时候能少修改一点，不断通过多做少修改，提高胜率。
小蒋还是比较强调策略的。判断这个东西，理解个思路就好，策略才是提高胜率的东西。
如果你是商城系统的设计者，小蒋建议把促销的变化和复杂性封禁在促销模块内部。不能让一个促销模块把整个电商系统都搞得非常复杂，一定要根据企业现阶段的业务情况，去设计和实现。一个设计方案，必须考虑方案的可行性和可落地性。
互联网系统的另外一个策略就是 小步快跑 通过不断地小版本的迭代，不停地进行商业可行性的验证。这个阶段，不要过多的考虑性能问题。只有商业模式可行性通过后，也就是系统可以稳定的赚钱了，才会扩大推广。所以，商业模式稳定后，才要开始考虑系统的性能问题，也就是所谓的高可用、高并发、系统容量、技术架构等等问题。小步快跑能够有效的控制投入。就好比你一下子开发了一个大系统，用的时候才发现根本就不是那么回事，系统要满足现实业务，需要重构。俗话说“步子迈大了，容易拉胯”，这是一个道理。
这就是策略的作用，未来小蒋将会和大家一起完善我们的架构策略。
思考
小蒋带着大家，咱们一起了解了电商系统的概要设计，那么接下来咱们一起来思考一个问题，如果让你自己设计一个电商系统，你会如何考虑。
咱们做产品的同学需要思考一下：
- 商城系统中的会有哪些角色？
- 核心业务流程是什么？
- 需要划分成几个模块？为什么？
咱们做技术同学需要思考一下：
- 使用那些技术栈？分别解决业务中哪个场景的问题？
- 需要哪些第三方的框架和云服务？
- 我们的存储系统该怎么选型？
这些问题，小蒋将会在后面的分享中，继续与大家交流的。
年龄的增长不可怕，可怕的是从未成长！
感谢大家支持小蒋，小蒋希望和大家共同成长，谢谢。