Gstore 项目重构
为什么要重构？
主要原因有2个：
- 当前商城的数据库中包含了太多无用的表或者结构，这些结构从一定程度上也影响了新需求的设计。也有很多结构是冗余的，无用的，设计不合理的，例如订单中保存了多个车辆相关的字段，msisdn，vin等等，这些实际上跟订单这个业务并不是完全关联的，可能只有部分场景相关。
- 现在4个商城的代码混杂在一个商城的项目中，这个项目中也混杂了多个领域的业务，商品库存、订单、分类、品牌、banner、优惠活动。最直接导致的一个问题就是，比如一个新需求是针对应用商城安装包（也被视为一个商品）的，那么一旦去做这个新需求，发生一些数据库或者代码的改动，其结果很可能会影响到其他的商城（虽然在代码中现在已经做了一些商城的分离处理，但是还是难免会有遗漏）。
怎么重构？
结合上两条问题的起因，我们将整个商城也分为2步重构。
- 拆分各个商城，抽离出各个具象的业务，以及保留商城元系统。
- 抽象化商城元系统，并拆分系统领域，即拆分子系统。
系统架构
子系统：
- tsp-store 商城库存系统
商城元数据的系统 - tsp-order 订单系统
处理订单业务的系统 - tsp-activity 商城活动系统
处理商城活动相关业务的系统
具象系统：
- tsp-app-store 应用商城系统
- tsp-theme-store 主题商城系统
- tsp-point-store 积分商城系统
- tsp-flow-store 流量商城系统
数据库设计
库存系统表结构：
应用商城表结构：
主题商城表结构：
订单系统表结构：
优点：
- 各个商城专注于自己的业务，新业务没有耦合。
- 商城拆分成3个子系统，减少子系统之间的耦合。
- 后续维护方便，新来的同事也能很快入手，系统的扩展性也更好。
缺点：
- tsp-store中的元数据混在一起，单纯的作为一个仓库。
- 一定量上肯定是加大了开发成本。
遇到的问题
- 像tsp-store这种元系统，本身只是提供给其他服务用，不提供对外的接口，这种服务是否符合微服务的整体架构？
- 如何很好的抽象出元数据？这个是比较重要的步骤，因为一旦元系统的结构变动，会影响到上层的服务（或者这里可以在元数据提供的入口中做一些低内聚的操作）
- 未来比较麻烦的一点是，为了兼容老商城的部分，新的商城系统主要负责做新的需求，如何能最大程度上从旧的商城剥离出来，这也是个需要注意的地方。