新公司很快就成立了，你成为了新公司的CTO。 对于改变世界，目前唯一可以确定的是网站商场系统软件，首先要建设一个电子商务系统。 目前尚不清楚具体会做什么。 您需要与老板讨论业务需求。
故事已经发展到这一步了。 作为一名程序员，你是否有一种似曾相识的感觉？ 现实情况是，需求从来都不是明确的，而且总是在变化。 唯一不变的是变化。 优秀的程序员能够适应变化并拥抱变化。 在需求还不明确的情况下，比较可行的方案是先构建一个不太可能改变的核心系统，然后尽可能简单地实现一个最小系统，然后逐步迭代和完善。
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个模块是不够的，因为我们只分析了“购物”这个最重要的流程，并没有完全覆盖业务需求中的所有用例，比如业务人员采购商品、经理查看报表等所覆盖的情况。
与购物流程相比，剩下的用例和流程都相对简单。 我们可以用同样的方法来分析其他功能模块。 这里省略分析过程，直接给出我们要实现的电子商务系统的功能模块划分（如图1-4所示）。
▲图1-4 电子商务系统功能模块划分
图1-4使用UML中的Package Chart来表示电子商务系统的功能模块。
整个系统按照功能可分为10个模块。 除了购物流程涉及的产品、订单、购物车、支付、库存5个模块外，还补充了促销、用户、账户、搜索推荐、报告5个模块。 模块，这些是构建电子商务系统必不可少的功能模块。 下面我们一一解释一下各个模块需要实现的功能。
产品：维护和显示产品相关信息。 订单：维护订单信息和订单状态，并计算订单金额。 购物车：维护用户购物车中的产品信息。 支付：负责与系统内外的支付渠道对接，实现支付功能。 库存：维护产品的库存信息。 促销：制定促销规则，计算促销折扣信息。 用户：维护系统的用户信息。 注意，用户模块是业务模块，一般不负责用户登录和认证。 这是两个完全不同的功能。 账户：账户模块负责维护用户的账户信息。 搜索推荐：提供商品搜索功能，负责各类商品列表页、促销页的整理和展示。 简单来说，搜索推荐决定了用户首先看到哪些产品。 报表：实现数据统计和分析功能，生成报表，为管理者进行业务分析和决策提供数据信息。
这里需要说明的是，促销模块是电商系统中最复杂的模块。 各种优惠券、满折、返现等促销规则都非常复杂。 此外，这些规则通常需要相互叠加计算。 有时甚至复杂到连制定晋升规则的人都搞不清楚。
所有电商企业无一例外地在制定促销规则时出现失误，导致商品的实际售价远低于成本价，使企业遭受一定程度的损失。 尽管如此，各种促销活动仍然是增加销量最有效的手段，因此需要充分利用。
作为电商系统的设计者，我们需要控制促销模块内促销规则的变化和复杂性。 我们不能因为一个促销模块就让整个电商系统变得非常复杂，否则设计和实现都会很困难。
一种可行的做法是，将促销模块与其他模块之间的接口设计得相对简单且固定，这样系统的其他模块就不会因为新的促销规则的变化而发生变化。
创建订单时，订单模块需要将商品和价格信息传递给促销模块。 促销模块返回可以使用的促销列表。 用户选择相应的促销和折扣。 订单模块再次传输产品、价格、促销优惠等信息。 促销模块将促销后的价格返回给促销模块。 在最终生成的订单中，系统只需要记录订单中使用了哪些促销规则以及最终的促销价格。
这样，无论促销模块怎么变化，订单等其他模块的业务逻辑都不需要做相应的变化。
至此，我们就完成了一个电子商务系统的概要设计，大家应该对电子商务系统有了初步的了解。
03 总结
让我们回顾一下电子商务系统设计中包含的核心点。
首先，电子商务系统的角色是：用户、运营者和管理者。 这三个角色对于电商系统的需求是：用户通过系统购物，运营商负责销售商品，管理者关注系统中的业务数据。
电子商务系统的核心流程是用户的购物流程。 购物流程从用户浏览购买商品、添加购买、下单、付款、运营商发货、用户确认收货开始。 至此，电商系统的购物流程结束。
细化这个流程后，我们可以分析支撑这个流程的核心功能模块：产品、订单、购物车、支付、库存。 此外，一个完整的电子商务系统还包括促销、用户、账户、搜索推荐和报告等必要的功能模块。
作为一名开发人员，在做需求分析时，需要把握的一个关键点是：不要一开始就设计功能，而是先明确业务需求。 这也是本文反复强调的两个问题：这个系统是为谁服务的？ 他们使用这个系统来解决什么问题？ 这确保了最终的系统通常不会偏离用户的期望。
最后，在讲解系统功能模块划分时，介绍了一种可以有效降低系统复杂度的设计经验。 也就是说，如果系统业务复杂多变，那么尽量找准这部分复杂业务的边界，将复杂业务控制在一个模块内网站商场系统软件，避免这种复杂性扩散到整个系统。
作者简介：李跃，美团基础技术部高级技术专家，极客时光《后端存储实战教程》、《消息队列大师教程》等专栏作者。 曾就职于浪潮集团、当当网、京东等公司。 多年从事互联网电商行业基础设施领域的架构设计和研发工作，多次参与双十一、618电商促销活动。 专注于分布式存储、云原生架构下的服务治理、分布式消息和实时计算等技术领域，致力于推动基础设施技术的创新和开源。
本文摘自《电商存储系统实战：架构设计与海量数据处理》，经出版社授权。 （国际标准书号：978-7-111-69741-1）