引言
我们的故事从一个电话开始。
某一天，一个曾经认识但并不太熟悉的老板，突然来了一个电话：
新公司很快就成立了，你成了新公司的 CTO。
关于要如何改变世界，目前唯一能确定的是，老板要做一个电商系统。具体做成什么样，还不清楚。你需要和老板讨论需求。
有没有感觉似曾相识？作为研发，谁没碰到过几个啥也不懂的需求方不是？
那这种情况下，你怎么办呢？
在需求还不太明确的情况下，比较可行的方式就是，先把那些不太会变化的核心系统搭建出来，尽量简单地实现出一个最小化的系统，然后再逐步迭代完善。
电商系统的核心流程是什么样的？
接下来我们一起来设计这个电商的核心系统。
遵照软件工程的一般规律，我们先从需求阶段开始。
如何来做需求分析？
理想情况下，应该由系统分析师或者是产品经理来承担这个任务。但现实很骨感，绝大多数情况下，你得到的所谓的“需求”，就是一两句话。需求分析的工作实际上就落在了开发者身上。
很多项目交付以后，还要改来改去，用户不满意，开发者很痛苦，其实就是缺失了需求分析这个步骤。所以，为了自己，每一个开发者都应该掌握一点需求分析的方法。
开发者怎么来做需求分析？这里面我们不讲那些做需求分析的方法和理论，只告诉你最重要、最关键的一个点。
不要一上来就设计功能，而是先要回答下面这两个问题：
这两个问题的答案，我把它们称为业务需求。
在我们将要设计的这个电商系统中，它的业务需求是什么？电商的业务，每个人都熟悉，很容易回答这两个问题。
第一个问题，电商系统给哪些人用？
首先得有买东西的人，我们叫“用户”，还得有卖东西的人？我们叫“运营人员”。还有什么人会用这个系统？老板啊！你记住，你在设计任何一个系统的时候，千万不要把老板或者是领导给忘了，他们是给你钱的人，他们的意见非常重要！
然后我们一起回答：
第二个问题：用户、运营和老板，分别用电商系统来干什么？
这个问题也很容易回答，用户用系统来买东西，运营用系统来卖东西，老板需要在系统中看到他赚了多少钱。
这两个问题的答案，或者说是业务需求，稍加细化后，可以用下面这个图来清晰的表述：
这个图在 UML（统一建模语言）中称为用例图（Use Case），是需求分析的时候你需要画的第一张图。它回答的就是，业务需求中的那两个关键的问题，这个系统给谁用？他们用这个系统解决什么问题？
一般来说，业务需求和我们要设计的系统关系不大。
为什么这么说呢？你可以看一下上面这个图里面的用例，放在传统的商业企业里面，比如一个小杂货铺、一个线下实体商场商店或者一个做电视购物的公司，是不是也是适用的？
所以，做业务需求的主要目的，是理清楚业务场景是什么样的。
然后我们来分析电商系统的流程。
显然，一个电商系统最主要的业务流程，一定是购物这个流程。你应该很容易就能把这个流程分析出来，它的流程图是这样的：
所有的电商几乎都是这样一个流程，我和你一起来看一下这个流程。
如何根据流程来划分功能模块？
接下来，我们把这个业务流程再细化，看一下电商系统如何来实现这个流程？细化之后的流程，绘制成了下面这个时序图（Sequence Diagram）：
我们一起看下这个时序图中的每个步骤。
这个流程涉及到的功能模块有：商品、购物车、订单、支付和库存，这几个模块就是一个电商系统中的核心功能模块。
当然，仅仅有这几个模块还是不够的，因为我们只分析了“购物”这个最主要的流程，并没有完全涵盖业务需求中的全部用例，比如：运营人员进货、老板查看报表这些用例还没有覆盖到。
相比购物这个流程，剩下的几个用例和流程都没那么复杂，用同样的方法就可以把其他功能模块分析出来。
在这里，我们就省略分析过程，直接给出我们电商系统的功能模块划分：
上面这个图，使用的是 UML 中的包图 (Package Diagram) 来表示。
整个系统按照功能，划分为十个模块，除了购物流程中涉及到的：商品、订单、购物车、支付、库存五个模块以外，还补充了促销、用户、账户、搜索推荐和报表这几个模块，这些都是构建一个电商系统必不可少的功能。
我们一个一个来说每个模块需要实现的功能。
这里面需要特别说一下促销模块，它是电商系统中，最复杂的一个模块。
各种优惠券、满减、返现等等这些促销规则，每个都非常复杂，再加上这些规则叠加计算，常常是复杂到连制定促销规则的人都搞不清楚。
所以，每个电商公司无一例外都爆出过，因为促销规则制定失误，而产生非常便宜的“羊毛单”，让精明的消费者薅了“羊毛”。不过五花八门的促销是提升销售最有效的手段，肯定不能因噎废食。
作为系统设计者，我们需要把促销的变化和复杂性封禁在促销模块内部，不能让一个促销模块把整个电商系统都搞得非常复杂，否则就很难去设计和实现。
可行的做法是，把促销模块与其他模块的接口设计的相对简单和固定，这样系统的其他模块就不会因为新的促销玩儿法而改变。
最终生成的订单中，只记录订单使用了哪几种促销，以及最终的促销价就可以了。这样，不管促销这个模块的玩儿法怎么变化，订单和其他模块的业务逻辑不需要随之改变。
关于促销，还有一个点在实际运营的电商系统中，也需要经常考虑到：要在订单中要存储每个商品所均分的促销价。
比如A商品100元，B商品100元，用户买了一件A+一件B，激发了一个促销满200减10元，则每个商品均摊5元。核心是为了在做单件售后的时候，计算出首先对应的金额。
至此，我们就完成了一个电商系统的概要设计，你应该对电商系统也有了一个初步的了解了。
总结
我们一起回顾一下：一个电商系统的设计中，最核心的几个关键点。
首先，系统的角色是：用户、运营人员和老板。这三个角色对电商系统的需求是：用户使用系统来购物，运营人员负责销售商品，老板关注系统中经营数据。电商系统最核心的流程就是用户购物的流程，流程从用户浏览选购商品开始，加购、下单、支付、运营人员发货、用户确认收货，至此流程结束。
细化这个流程之后，我们可以分析出，支撑这个流程几个核心的功能模块：商品、订单、购物车、支付和库存。此外，还需要促销、用户、账户、搜索推荐和报表这些必备的功能模块支撑，才能构成一个完整的电商系统。
还分享了作为一个开发者，你在做需求分析的时候，需要把握的一个要点：不要一上来就设计功能，而是要先理清业务需求，先回答两个问题：这个系统是给哪些人用的？他们分别用这个系统来解决什么问题？这样可以确保你做出来的系统，大体上不会偏离用户的预期。
最后，在系统功能模块划分时，分享了一个有效减少系统复杂度的设计经验。那就是，如果系统业务是复杂而多变的，尽量识别出这部分复杂业务的边界，将复杂封禁在一个模块的内部，避免这种复杂度扩散到整个系统中去。
思考题
做完了概要架构设计，就可以来做技术选型了。
作为公司的 CTO，请你思考一下，这个电商系统的技术选型应该是什么样的？
期待、欢迎你留言或在线联系，与我一起讨论交流，“一起学习，一起成长”。
推荐阅读
- 架构师：不想当架构师的程序员不是好程序员
- 架构师技能修炼图
- 技术破局，业绩狂飙十倍：亿级电商平台重构大揭秘
- 当我们聊高并发时，到底是在聊什么？如何真正地掌握高并发设计能力？
- 【总结】我的十二个架构设计原则
- 微服务架构实战 - 我的经验分享总结2019（系统架构师）架构演进过程-从信息流架构到电商中台架构
系列分享
------------------------------------------------------
------------------------------------------------------
关于我（个人域名，更多我的信息）
期望和大家 一起学习，一起成长，共勉，O(∩_∩)O谢谢
如果你有任何建议，或想学习的知识，可与我一起讨论交流
欢迎交流问题，可加个人QQ 469580884，
或者，加我的群号 751925591，一起探讨交流问题
不讲虚的，只做实干家
Talk is cheap，show me the code