商城业务心得

这是我进入公司可以算是第一个从设计到完成的项目，起初在我的设想下商城并没有那么复杂，但是我发现在实际的开发中，我在不断地把我的原先的设计思路发杂化。

商城模块

1.商品模块
2.订单模块
3.支付模块

1. 对于第一个模块的难点在于规格的三级裂变，需要用父子级的商品规格来进行设计，使用了三个for循环对规格进行新增和修改。其余并无太多的重难点。
2. 对于第二个模块订单模块的难点在于我前期对于每个订单都做了商品以及规格关联，所以在后续的订单导出，以及订单查询都反复使用了多次查询，以及设计了视图，非常的浪费资源，经过这次设计我意识到应该存在订单留痕，订单的商品信息不应该会受到初始订单的变动影响，应保留下单时候用户信息以及订单信息。设计之初想着说节省资源，没想到实际使用起来反而是更浪费资源，以及更加的不合理。
3. 后面商城升级1.2版本的时候，把信息都留在订单之中。还有就是对于需求之中要求的付款订单才生成订单流水号，采用了双流水号设计模式，自用雪花id作为订单号，而按顺序排列的流水号在支付完成后采用了redis的方式按序生成。
4. 对于支付模块一开始采用了别人的第三方jar包，经过修改使用也并无问题，后来意识到别人的jar包可能有隐藏的未知威胁代码。所以重构了支付模块，借鉴了别人的优秀代码，去除一些未知的，安全性不高的第三方工具包，只留下支付宝的官方jar包进行开发，并打算在后期封装成一个自我开发的jar包，封装成payutils，对支付进行一行代码般的简化。 支付模块遇到在收到回调的时候使未生效的订单生效，并赋予其订单流水号。
5. 在重构的时候学习别人采用了strategy设计模式对支付模块进行设计。只需要使用payutils进行一行代码调用，所需要的参数都封装在VO实体类中。
6. 修改的中途发现几个可优化点。多重复合查询的条件非常多，可封装成一个实体类进行API标注，即美观又能减少代码量。还有就是封装vo的时候可以用json工具类进行转换而不用一个个put。
7. 在总结的时候有了新思路，对短链接有了新的想法，并且对操作人应该进行留痕。

规约问题

在设计之处，因为我选择的框架问题，也由于个人对R的返回并没有深入的理解，在这次设计中学习到了R其实是一个通用的并无进行状态码以及用途封装的实体类，我们一般在框架设计之初，就应该对返回值以及一些常用值进行规约，对R实体类进行二次封装，用上定义好的状态码以针对不同的状态码返回不同的东西。

业务功能

1. 新增/编辑商品：新增一个商品，规格最高为三层，最多为27个选项。可上传视频以及最多支持六张图片。
2. 上架商品：支持改变商品状态，非上架状态可编辑。非上架状态不可访问以及下单。
3. 商品列表：后台对商品按创建时间排序，销售端按商城和销量进行排序。
4. 提交订单：支持对上架商品进行下单，并采用支付宝进行支付。
5. 订单查询：对已经支付成功的订单进行查询，未支付的不会展示。
6. 订单退款：由主管理员指定权限，对已支付订单进行退款，对退款理由进行留痕。(1.2.2增加留痕，对操作人进行留痕。)