导读：电商业务与我们的生活息息相关，大家可能对电商多少也有一些了解 ，事实上 ，即使是一个最小化的电商系统，也依然是非常复杂的。
所以 ，我们先花一点时间 ，一起以一个创业公司的CTO的视角，设计一个最小化的电商系统 ，并以此理清电商系统的架构 。让大家对电商系统的业务逻辑、系统架构、核心业务流程有一个基本的认知 。
新公司很快就成立了 ，你成了新公司的CTO。关于改变世界，目前唯一能确定的是 ，首先要做一个电商系统 。具体要做成什么样 ，目前还不清楚 。你需要与老板讨论业务需求。
- 你：“咱们要做的业务模式是C2C 、B2C还是B2B呢？”
- 老板：“什么B？什么C？我不懂你说的那些技术名词 。”
- 你：“这么说吧，你要做一个某宝网 ，还是某东网 ，还是某848网呢？ ”
- 老板：“不都是一样的吗？它们之间有什么区别？你赶紧做一个出来我看看不就知道了？！ ”
故事发展到这里，作为程序员的你是不是有一种似曾相识的感觉？现实就是，需求永远不明确 ，永远在变化 ，唯一不变的只有变化 。优秀的程序员适应变化，并且拥抱变化。在需求还不太明确的情况下 ，比较可行的方案就是 ，首先搭建不太会发生变化的核心系统，然后尽量简单地实现一个最小化的系统 ，后续再逐步迭代和完善 。
01 设计电商系统的核心流程
接下来 ，我们一起设计这个电商的核心系统 。
遵照软件工程的一般规律，我们先从需求阶段开始。那么 ，需求分析应该如何做呢？理想情况下 ，系统分析师或产品经理应该负责完成需求分析的任务 。但是，现实中绝大多数情况下 ，你得到的所谓的“需求” ，很有可能就是一两句话 。需求分析的工作最终往往是由开发者完成的。
很多项目交付以后，仍需要不断地进行修改和变更，用户不满意 ，开发者也很痛苦 ，造成这个问题的根本原因其实就是缺失了需求分析的步骤。所以，为了后续工作能够顺利开展 ，每位开发者都应该掌握一些用于需求分析的方法 。
那么 ，开发者进行需求分析时应该做些什么呢？这里先不介绍那些做需求分析的方法和理论，只告诉你最重要 、最关键的一个点：不要一上来就设计功能 ，而是先明确下面这两个问题的答案 。
- 这个系统（或者功能）是给哪些人用的？
- 这些人使用这个系统是为了解决什么问题？
这两个问题的答案 ，我们称之为业务需求。那么，对于我们将要设计的电商系统 ，其业务需求又是什么呢？如果大家很熟悉电商的业务 ，那么回答这两个问题应该很容易 。
第一个问题，电商系统是给哪些人用的？首先是买东西的人 ，即“用户 ”；其次是卖东西的人 ，即“运营 ”；还有一个非常重要的角色就是出钱的人，即“管理者”（请记住，在设计任何一个系统的时候 ，管理者的意见都是非常重要的） 。综上所述 ，电商系统是面向用户、运营和管理者开发的。
第二个问题，用户 、运营和管理者使用电商系统分别想要解决什么问题？这个也很容易回答 ，用户为了买东西 ，运营为了卖东西，管理者需要通过系统了解自己所得的收益 。
这两个问题的答案 ，或者说业务需求 ，稍加细化后，可以用图1-1进行清晰的表述 。
▲图1-1 电商系统用例图
图1-1在UML（统一建模语言）中称为用例图（Use Case） ，是我们进行需求分析的时候所要画的第一张图。用例图可用于回答业务需求中的两个关键问题 ，即这个系统给谁用？他们用这个系统是为了解决什么问题？
一般来说，业务需求与我们要设计的系统关系不大 。为什么这么说呢？因为我们将图1-1中的用例 ，放在传统的商业企业（比如 ，一个小杂货铺 、一个线下实体商场或商店，或者一个做电视购物的公司）中也是适用的，所以 ，做业务需求的主要目的是理清楚业务场景是怎样的 。
下面就来分析电商系统的业务流程。很显然 ，电商系统最主要的业务流程，一定是购物流程 。购物流程很简单 ，具体流程如图1-2所示 。
所有电商的购物流程几乎都是如此 ，下面就来分析一下这个流程。
▲图1-2 电商系统购物流程图
流程从用户选购商品开始，用户首先在App中浏览商品 ，找到心仪的商品之后 ，把商品添加到购物车，选完商品之后 ，打开购物车 ，提交订单。下单结算之后，用户就可以支付了 。支付成功后 ，运营人员会为已经支付的订单发货 ，为用户邮寄相应的商品 。最后，用户收到商品并确认收货。至此，一个完整的购物流程就结束了 。
02 根据流程划分功能模块
接下来 ，我们再进一步细化电商购物的业务流程 ，看一下电商系统是如何实现该流程的 。图1-3所示的是细化之后的电商系统购物流程时序图（Sequence Diagram）。
▲图1-3 电商系统购物流程时序图
下面就来详细讲解图1-3所示的时序图中的各个步骤 。
- 用户浏览商品，这个步骤需要通过一个商品模块来展示商品详情页 ，用户可以从中获取所浏览商品的详细介绍和价格等信息 。
- 然后 ，用户把选好的商品加入购物车，这个步骤需要使用一个购物车模块来维护用户购物车中的商品。
- 接下来是用户下单 ，这个步骤需要基于一个订单模块来创建新订单 。订单创建好了之后 ，系统需要把订单中的商品从购物车中删减掉 。
- 订单创建完成后，系统需要引导用户付款 ，即发起支付流程 ，可通过一个支付模块来实现支付功能，用户成功完成支付之后 ，系统需要把订单的状态变更为“已支付 ”。
- 成功支付之后 ，运营人员就可以发货了，发货之后，系统需要扣减对应商品的库存数量 ，这个步骤需要基于一个库存模块来实现库存数量的变更 ，同时系统还需要把订单状态变更为“已发货 ” 。
- 最后，用户收到商品 ，在系统中确认收货 ，系统需要把订单状态变更为“已收货”，流程结束 。
这个流程涉及5大功能模块 ，即商品、购物车 、订单 、支付和库存 ，这5大模块就是一个电商系统中的核心功能模块。
当然，仅有这5个模块是不够的 ，因为我们只分析了“购物 ”这个最主要的流程 ，并没有完全涵盖业务需求中的全部用例，比如 ，运营人员进货、管理者查看报表等还没有覆盖到。
相比购物流程 ，剩下的几个用例和流程都相对简单一些，我们可以采用同样的方法来分析其他的功能模块 。这里将省略分析过程，直接给出我们所要实现的电商系统的功能模块划分（如图1-4所示） 。
▲图1-4 电商系统功能模块划分
图1-4使用了UML中的包图（Package Diagram）来表示电商系统的功能模块。
整个系统按照功能 ，可以划分为10个模块 ，除了购物流程中涉及的商品 、订单 、购物车、支付和库存这5个模块之外，还补充了促销 、用户 、账户、搜索推荐和报表这5个模块 ，这些都是构建一个电商系统必不可少的功能模块 。下面就来逐一说明每个模块需要实现的功能 。
- 商品：维护和展示商品的相关信息。
- 订单：维护订单信息和订单状态 ，计算订单金额 。
- 购物车：维护用户购物车中商品的信息 。
- 支付：负责与系统内外部的支付渠道对接，实现支付功能。
- 库存：维护商品的库存信息 。
- 促销：制定促销规则 ，计算促销优惠信息 。
- 用户：维护系统的用户信息 ，注意，用户模块是一个业务模块 ，一般不负责用户的登录和认证 ，这是两个完全不同的功能。
- 账户：账户模块负责维护用户的账户信息 。
- 搜索推荐：提供商品搜索功能，并负责各种商品列表页和促销页的组织和展示 ，简单地说就是 ，搜索推荐决定用户优先看到哪些商品 。
- 报表：实现数据统计和分析功能，生成报表，为管理者进行经营分析和决策提供数据信息。
这里需要特别说明的是 ，促销模块是电商系统中最复杂的一个模块。各种优惠券、满减 、返现等促销规则 ，每一条都非常复杂，再加上这些规则往往还要叠加计算 ，有时甚至会复杂到连制定促销规则的人都算不清楚 。
所有电商公司无一例外都曾因为促销规则制定失误 ，导致商品实际售价远低于成本价，使公司受到一定程度的损失 。尽管如此 ，五花八门的促销活动依然是提升销量最有效的手段 ，因此需要充分利用。
作为电商系统的设计者，我们需要把促销规则的变化和复杂性控制在促销模块内部 ，不能因为一个促销模块而导致整个电商系统都变得非常复杂 ，否则设计和实现将会很难 。
一种可行的做法是，把促销模块与其他模块的接口设计得相对简单和固定 ，这样系统的其他模块就不会因为新的促销规则改变而随之进行改变 。
在创建订单时 ，订单模块需要把商品和价格信息传给促销模块，促销模块返回一个可以使用的促销列表，用户选择对应的促销和优惠 ，订单模块把商品 、价格、促销优惠等信息 ，再次传给促销模块，促销模块再返回促销之后的价格。在最终生成的订单中 ，系统只需要记录订单使用了哪几种促销规则 ，以及最终的促销价格就可以了 。
这样，无论促销模块如何变化 ，订单和其他模块的业务逻辑都不需要随之改变 。
至此 ，我们就完成了一个电商系统的概要设计，大家对电商系统应该也有了一个初步的了解。
03 小结
下面就来回顾一下一个电商系统的设计中所包含的核心要点 。
首先 ，电商系统面向的角色是：用户 、运营人员和管理者 。这三个角色对电商系统的需求是：用户通过系统来购物 ，运营人员负责商品的销售，管理者关注系统中的经营数据。
电商系统最核心的流程是用户购物的流程 ，购物流程从用户浏览选购商品开始 ，加购 、下单、支付 、运营人员发货 、用户确认收货，至此电商系统的购物流程结束 。
细化这个流程之后，我们可以分析出支撑这个流程的核心功能模块：商品、订单 、购物车 、支付和库存 。除此之外 ，一个完整的电商系统还包括促销、用户 、账户 、搜索推荐和报表这些必备的功能模块。
作为一名开发者 ，在做需求分析的时候，需要把握的一个要点是：不要一上来就设计功能 ，而是要先理清业务需求。这也是本文反复强调的两个问题：这个系统是给哪些人用的？他们分别用这个系统来解决什么问题？这样就可以确保做出来的系统大体上不会偏离用户的预期 。
最后 ，在讲解系统功能模块划分的时候，介绍了一个能够有效降低系统复杂度的设计经验 。那就是 ，如果系统业务是复杂而多变的 ，那么请尽量识别出这部分复杂业务的边界，将复杂业务控制在一个模块内部 ，从而避免将这种复杂度扩散到整个系统中去。
还没有评论，来说两句吧...