在将通用接口平台开源改造过程中，遇到了一些问题，整理出来，作为番外篇。
背景
有一个开发平台，实现了系统内核，包括组织机构、人员、角色、权限项、日志、缓存等，以及部分扩展能力，如任务调度、附件、桌面等。
在开发平台的基础上，去做业务系统的开发，例如进销存系统、SRM、CRM、物流系统等。
目的是系统技术支撑能力由开发平台提供，业务系统专注于业务逻辑的开发。
通用接口平台名字虽然叫平台，本质上也是基于开发平台构建的一套业务系统。
最初的时候，为了简单高效，只创建了单个模块，开发平台与业务系统偶合在一块，通过包来区分。
从架构设计角度考虑，这样做是不合理的，需要解耦，将通用接口平台这个业务系统剥离出来。
目标
开发平台是公用的，可以不断完善提升，独立升级。
多个业务系统公用一套开发平台。
挑战
平台公用，独立升级：一方面，业务系统需使用公用平台，如果一套业务系统一套平台，则平台的代码难以复用；另一方面，平台应保持独立，提供技术支撑能力。
技术组件按需加载：部分公共通用技术组件几乎是必然会用到的，比如日志、缓存、任务调度，适合放到开发平台，但有些技术组件则是某些业务系统才会用到的，比如工作流、消息队列、规则引擎，因此需要处理好这部分组件，全部加载会使平台很重，会降低编译、运行速度，增大发布包体积，因此最好通过配置来实现按需加载。
方案
方案1 微服务架构
微服务架构适用于单个业务系统内部不同模块或业务域的拆分与部署，当前我们是在一套开发平台上开发多个业务系统，并且业务系统之间没有关系，因此该方案并不适合。
此外，微服务架构需要微服务框架的支撑，微服务框架需要独立维护和部署。
方案2 单体应用架构
单体应用架构又分为几种模式：
一是业务系统部分的代码和平台的代码在一个项目中，没有解耦，无法复用
二是二者都是独立的springboot项目，相当于1前端多后端，身份认证方面比较困难，更像是微服务架构
三是将开发平台构建为jar包，不要独立运行，而是作为业务系统的依赖包
综合考虑，第三种模式最可行，实际也就是传统软件厂商长期采用的模式。
