简介
完整的一套毕设级别项目，用于学习如何原生开发微信小程序，以及使用前端技术栈搭建较为完善的后端 Web 服务。
feature
- theme、banner 业务划分
- activity & 优惠券业务支持
- 商品分类
- 购物车业务
- 订单业务
- 延迟支付功能
- 用户登录
- 真实微信支付接入
对优惠券业务和订单业务做简单介绍，其余功能请扫码体验。
TODO：二维码
优惠券
用户只有在进行登录授权后，才可领取优惠券。并且优惠券是有品类限制和使用条件的，在品类上分为全场券和品类劵，在使用条件上除了上述有可能存在品类限制外，还需要达到一定金额方可在支付时使用。因此大体有如下种类优惠券：
- 全场无门槛减免劵
- 甜点满 100 减 30 优惠券劵（单个类型限制）
- 主食和热菜满 508 折优惠券（多个类型限制）
...
订单业务
当用户在购物车添加商品并触发下单逻辑后，后端首先需要对前端提交的数据进行详细校验，主要目的在于：
- 保证数据的准确性（牢记前端传递过来的数据可能会被篡改或者存在时差）
- 核查库存，防止负库存情况发生
随后进行库存的预扣除、优惠券的核销。当扣除和核销成功后，会为该订单生成一条数据并插入到数据库中，并将该订单信息推入到消息队列中间件中，以便在订单支付超时能够进行库存和优惠券的归还。
用户在下单完成后，可以选择在一段时间内进行支付，也可以手动取消，或者超出时间范围内自动取消订单。
TODO：支付成功后将数据写入到 MQ 中间件（提高并发能力），方便其他 RPC 业务（短信通知、仓库发货等）进行处理。
该项目是本人在做毕业设计时的产物，之所以拿出来分享并做教程，是因为当时在对整套系统进行技术选型时遇到了比较大的阻力。
如果不感兴趣，或者比较想直接看干货，请跳过该部分。
阻力
dataBase
首先我有一点数据库基础（停留在 MySQL 应知应会水平）以为数据库就那么简单，撸袖子干就行了。可见当时是有多无知。
后来随着不断开始设计数据库表时候，就明显觉得异样。当时脑子里并没有对于一个相对有点复杂系统有完整的设计思路，或者说是经验。
因为系统内部的每一个模块是有关联的，不是相互孤立的，所以最初版的数据库设计的跟屎一样。冗余字段、连表查询困难、连最基本的业务软删除硬删除都没有意识到，于是就开始找寻只跟数据库设计的书有关，或者说：能够快速教我如何设计这个数据库。
很显然，数据库好的书籍比比皆是，但教你如何设计一个系统，我还真没找到。于是在某网上找到一套课程，开始学习起来。这，就有了本套系统的数据库雏形。
但当时，比较大的阻力就是，如何将老师讲得东西迁移到自己的系统中？并能够用比较适合自己的技术栈给他应用起来？
经过很多资料的查询和尝试后，最终选择了 TS+typeORM 这种 ORM 去嫁接在 MySQL 之上。有几个原因：
- 我想学习 TS，并应用它。
- typeORM 语法很干练，类型注解用起来开发效率暴增
在开发的过程中，发现国内有的资料很少很少，官方文档也没有写全。往往很多时候需要去查询.d.ts 文件，如果还看不懂就要去 stackOverflow 和 typeORM 下面的 issue 查，查完自己还要反复试错。
因此就萌生了想把整个开发过程复盘下来，并分享给其他人。
webapi
同时在对 Web 框架进行选型时，由于我想尝试并学一下后端较为成熟的项目架构分层，就开始在 egg.js 和 Nest.js 之间进行选择。不是说 egg.js 不好，只能说我火候还差的太远我用不好，或者说理解不好。于是便选择了 nest.js 作为整套项目 Web 后端框架，同上述数据库一样，依然国内没有较为体系的、较为细致的教程。nestJS 官方文档虽然还不错，但是能够直接看文档就拿他撸一个项目，还需要有一定功底的。（除非你的项目根本就是小 demo，好多问题不考虑的那种。）
更何况后面由于项目存在一定复杂度，需要通过接入延迟消息队列去解耦业务时，自己又是趟了一把 rabbitMQ 的坑。因此更加坚定了自己写教程的想法。
技术栈
前端：微信小程序 + LinUI 组件库
后端：TypeScript + MySQL（typeORM）+ Nest.js + rabbitMQ
部署：Docker + Docker Swarm + CentOS + Nginx
技术难点
- 实现一个功能的思维路径是怎样的？
- 如何设计合理的订单系统？
- 如何设计并实现优惠券活动？
- 如何实现高效的延迟支付功能？
- 如何通过 Docker 部署可拓展集群？
沉淀
闭环思维提升
并不是认不清自我要往全栈发展，只是作为一名 RD 人员，应该在力所能及的情况下对整个研发流程有一定理解和体会。这样在多人协作时才能发挥出最大价值，并且在一定程度上进行能够换位思考，而不是互相甩锅。
从一个 ide 产生，到具体落地需要几步？
设计规划 -> ... （接下来混乱了）
这就是当时我拿到课设题目时的状态，有主意但难实现。当时自己简单的学过一个 express 开发的项目 : （TODO：地址）
该项目较为简单，当时只是体验了一把 TS + express + GraphQL 开发的后端的乐趣，但并没有形成系统性的思维。
于是在经历某夜失眠后，将整个问题拆解成如下几个部分：
- 一个需求如何从前端到后端进行具体实现？
- 如何设计一个“能用的数据库”？
- 合理的后端分层是怎么做的？
- 如何部署一套“能用的“服务器？
在这漫长的修行之旅中，先后补充了如下知识：（如果需要，请私信我，我都会发给你~）
- 数据库设计
- Spring 设计电商（大体了解一下 Spring 写 webserver）
- docker 部署
- zero-to-nestJS
在这过程中，也参考了如下专栏：（TODO：地址）
将整个过程记录在该仓库中，一是为了能够给其他兄弟一些参考，另外是做一个自己的技术沉淀，毕竟好记性不如赖笔头。
虽然自己离真正的闭环还差的十万八千里，但好歹也是迈出了第一步~希望在下一个节点，能让这个圈儿，再壮实一把！
产出意识
凡是需要有“产出”，道理我都懂，但做的一直都不好。在学习前端知识的时候自己就有意识去产出，但都没有做的很满意。（TODO：仓库地址）
我想可能有如下原因：
- 学习资料比比皆是，感觉自己的总结对他人无用（其实是错误的观点）
- 枯燥乏味，难以坚持产出
- 缺少内驱力
但依然还是坚持在做产出，例如我自己的技术脑图（TODO：脑图截图）
但都没有达到能真正的解决其他人的问题，虽然自己收获的蛮多。但没有得到市场（他人）认可，就是失败的产出（消极了）。
于是这次重新上路，决定将自己对于每一个 feature 的理解、思维路径、以及实现过程中遇到问题如何解决都会详细记录。力图给 nodejs 社区添砖加瓦（努力做，一定可以的）。
TODO：（反复思考重整） 思维路径可以归纳为如下步骤：
对需求进行详细分析，提炼需求点
进行数据库设计 设计数据层（repository），思考数据库事务操作，找到核心点 分解业务层（service），对复杂的业务分解处理完毕后，交给上面分析过的数据层。 接口约定 设计控制层（controller），主要起到承上（http）启下（service）作用。 抽象DTO，... 接口保护 接口校验
整个分析过程会适当借助流程图辅助进行梳理，比如 jwt 登录鉴权、订单校验逻辑以及延迟消息队列的接入。
