admin模块的拆分逻辑
背景：目前三套系统的代码，都写在一个工程中，需进行系统拆分，为后续实现微服务做出铺垫
剥离原有工程
构想
admin模块剥离出来后，形成一个多模块项目。项目模块如下:
admin-api 存放controller层的内容、jsp页面和一些静态资源
admin-service 存放service接口和serviceImpl
admin-mapper 存放dao层接口和对应的mapper.xml文件
admin-common 存放实体类、工具类等等，其它模块都会用到的内容就放在该模块下
后续如果我们需要加gateway等等，在目前的工程结构基础上，添加新的模块
搭建工程结构，配置pom文件
模块之间的依赖关系如下：api -> service -> mapper -> common
将公共资源（如：工具类、实体类等）放入common模块
剥离完成后，如果工程可以跑通，进行下一步
实现
经过2天的时间，admin工程成功的被剥离出来。剥离过程本身难度并不高，主要就是把一些相关的文件copy到新工程对应的模块下，以及一些命名规范和包名的修改
难点
admin工程本身虽然技术栈已然落后于市场的主流，但是其业务体量、技术栈的数量都不是小数目，因此整个剥离过程中，主要有以下难点：
不确定剥离业务的完成程度
由于老工程中混杂了三套系统的代码，因此想要做到完美的admin工程剥离，需要删掉一些无用的业务代码。而删除业务代码的前提是，我们需要懂业务
admin工程剥离完成后，需要确认所有的开放API都可用
很尴尬的是，admin工程当初是由一个人独立完成的，所以我们是没有测试用例的，一个都没有…
经过我自己手动测试（点点点），地区推广中涉及到了一张被删除的表，以及几个NPE，算是初步完成了测试
解决
针对以上难点，解决方案如下：
- 开始着手梳理业务流程，从mapper层倒推controller层，判断哪些业务代码是无用的。每删除一段业务代码，需要手动测试这一块的对应功能（没什么难度，是个细活）
- 业务梳理完成后，进行一次完整的测试（不包括性能测试）
踩坑
昨天志超在做文件导出的功能，我才发现原来daemon模块也是需要迁移的，所以周五开始梳理daemon模块