开发平台模块化重构

背景

之前为了开发上的简便高效，整个开发平台源码基本上一体的，模块进行了粗略拆分，分了三块，一是platform-common，存放公用基础，如工具类、父类；二是popsoft-generator，也就是代码生成器，基于库表和模板技术快速生成entity、vo、dao、service、controller、ui的各层代码；三是platform-core，命名是核心模块，除了以上两个模块外，其他内容都放在这里面，框架类的放在的外围，内部建了一个包，按功能模块存放，不仅包括平台的功能模块，后来开发的业务系统，比如通用接口平台、文档管理系统、微信小程序后台，也都塞到了里面，大概的层次目录是下面这个样子。

这样面临的一个显著问题，是多个业务系统虽然从逻辑上隔离的，但是平台支撑是耦合在一起的，对于公共部分，如权限管理、身份认证什么的没什么问题，但对于个性化需求部分，例如全文搜索，仅文档管理系统才需要引入的组件，不应该在其他系统系统中引用。

我的目标是，开发平台是公用的，可以不断完善提升，独立升级；多个业务系统公用一套开发平台。

更具体点，也就是以下两点：
平台公用，独立升级：一方面，业务系统需使用公用平台，如果一套业务系统一套平台，则平台的代码难以复用与运维；另一方面，平台应保持独立，为业务系统提供强有力技术支撑能力。

技术组件按需加载：部分公共通用技术组件几乎是必然会用到的，比如日志、缓存、任务调度，适合放到开发平台，但有些技术组件则是某些业务系统才会用到的，比如工作流、消息队列、规则引擎，因此需要处理好这部分组件，全部加载会使平台很重，会降低编译、运行速度，增大发布包体积，因此最好通过配置来实现按需加载。

解决思路

参照spring-boot的解决方式，开发平台自身内部模块化，对外输出一个starter的jar包，业务系统引入该jar即可实现平台基础与内核功能，在其基础上专注于业务系统开发即可。

对于技术组件的集成，则做成类似spring-boot-starter-****的jar包，按需引用即可。

规划

平台核心模块

popsoft-platform：聚合项目，用于管理开发平台各模块的源码。
popsoft-common：公用基础，包括工具类
popsoft-framework：平台框架
popsoft-system：系统管理模块，包括组织机构、人员、权限、日志
popsoft-generator：代码生成器，基于库表和模板技术快速生成entity、vo、dao、service、controller、ui的各层代码
popsoft-boot-starter：平台启动项目，整合平台基础功能，类似于spring-boot-starter，业务系统引入该包进行依赖
popsoft-boot：启动项目，可视为业务系统模拟，用于平台自身功能开发与调试

业务支撑模块

popsoft-support：业务支撑，提供单据流水号、消息通知、内容模板、门户等功能

能力扩展模块

通常是中间件的集成，具体的业务系统按需依赖
popsoft-boot-starter-mail：邮件
popsoft-boot-starter-oss： 对象存储
popsoft-boot-starter-scheduler：任务调度
……

具体的实现，参见下篇。