前言

今年的目标每月至少写一遍文章，然而上月我食言了，所以内心里还是蛮不爽的。下面我会总结原因，其次既然没有完成计划，要做的就是找时间补上来。那我们今天这篇文章的内容是什么？我其实也不知道，因为我没有学习，没有学习的结果就是没有干货，我一直认为一篇好的文章是需要一段时间持续学习或者有意义的项目积累而产出的。想了一下，今天的这篇文章的主要内容是：

上月工作总结(PS:又工作总结，其实我也吐了，上月也是工作总结)。

DT的工作总结

为什么上月没有文章产出？

这个问题毫无疑问的答案：加班->没时间->没学习->没干货 || 加班->工作->…（此处省略n个字）。其实最后都落在了加班两个字上面了，我是特别反对加班这种行为的，关于加班我通常都会去反问“我们为什么要加班，导致加班的最根本的原因是什么？”，我对于一个问题喜欢刨根问底，我不喜欢自己骗自己，该是什么样就是什么样。但是我反对加班不代表我不参与加班，凡事都是活的，对吧～

可能又有人该要说了“时间都是挤出来的”，对，没错，我也挤了。希望下篇文章带来点干货，我会努力的～

上月的工作内容

九月份的工作内容如下：

• 商品预定(我是酱油)
• 收公司内部所有项目关于红包的CURD操作到服务

商品预订

功能简单描述：先预订单再指定时间付尾款，结果商品的交易过程中产出：预定单+尾款单

技术方案：

1. 生产两个订单：定金订单+尾款订单，下面统称为“两笔”技术方案
2. 一个订单多笔支付流水：1+n模型，下面统称为“1n”技术方案
   
   其实上面两个方案的关键点是是否生产多个订单，我个人还是比较倾向于1n,因为一个订单产生多笔交易流水我觉着足够的抽象，在我看来这是一个典型的1对n模型，也就是1个订单对多笔交易流水模型。通过这个模型我们简化了订单逻辑的复杂度，于此同时该模型可以用于例如分期购等场景。然而两笔的基本就定制的功能了，而且增加了订单相关的复杂度,个人觉着比较hack。如果有相关经验的大虾们可以给我留言解惑，谢了。

收公司内部所有项目关于红包的CURD操作到服务

功能简单描述：大概几个项目都有和红包相关的增删改查操作，红包的数据量也在日益增加，需要对红包相关进行拆库，拆库前需要做的工作就是写一个服务统一对外提供红包相关的CURD操作，然后对红包有依赖的地方调用服务即可。这样工作内容就很明显了，把相关的原始sql或orm操作替换成调用服务接口。

总结：

• 如果是我负责的项目，一旦有多个项目对某处存在以来，我一般都会考虑是否将其抽象成一个基础服务。

• 逻辑层满天飞的原声sql语句，无数的复制粘贴都增加了服务化工作的复杂性。“高内聚，松耦合”，还是那句话“尽可能的把数据模型的CURD操作写到模型层”。

• 前期没有简单的模块化项目，所有的业务耦合到了一个module里。

• 后台是直接读库还是读服务？模块化后台业务，直接读库即可，降低服务的复杂度和后台开发的复杂度，依赖服务业务量没达到一定的情况下没必要，单点登录统一的后台登陆和管理页。