背景

今年三月初，确定了自己将来很长一段时间要做的事情，再启程，从头开始，研发一套应用开发平台，完全开源，详见https://blog.csdn.net/seawaving/article/details/129334330。

从头开始，不是从零开始，大量的技术选型工作，平台设计与实现工作，都已实现，需要的大多是迁移和优化。

用了四个月的时间，基本完成了多年来设计与实现的平台功能迁移，正式发布4.2版本。
今天来做一个回顾和总结，说一说都做了哪些，以及未来的展望，规划后面要做哪些。

先放一张整体架构图

后端模块

后端做的主要工作是模块化重构，重构过程中不可避免会进行架构的调整与优化，比如某些功能需要下沉到底层公共基础模块，某些功能需要拆分为更小的颗粒度来提升复用。
到目前为止，整个工程项目，后端共计16个模块，架构图和依赖关系如下图所示：

这16个模块分成三类，一类是平台内核模块，命名规则是platform+模块功能名称，图中用蓝色标示；一类是能力扩展模块，命名规则是platform-boot-starter+模块功能名称，图中用绿色标示；剩下的一类是接口平台，命名规则是cip+模块功能名称，图中用紫色标示，相对平台独立，但又作为平台的重要组成部分。

下面来具体说一说各模块的职责以及包含的功能。

平台内核模块

platform-common作为公用基础模块，主要包括工具类、公用注解、公共父类、公共常量、公共枚举值，与前端UI交互定义的vo类，该模块为最基础的模块，无前置依赖。

platform-system是平台最核心的模块，主要包括组织机构、人员、角色（用户组）、权限、日志、系统参数、模块这些实体和服务的实现，需要注意的是，权限控制、日志记录，并不是在该模块实现，而是在platform-framework平台框架中实现，该模块依赖于platform-common。

platform-framework是平台框架，负责身份认证、权限控制、全局配置、数据分页、日志处理、自动填充（创建人、创建时间、修改人、修改时间），因为身份认证、权限控制等功能，不可避免需要使用处于platform-system模块中的人员、用户组等实体和服务，因此依赖于platform-system。

platform-support是一个业务支撑模块，基于技术组件进行功能设计与封装，实现一些通用的功能设计，更方便业务逻辑的实现，提供附件管理、通知公告、内容模板（用于短信、邮件、消息）、单据流水号、门户等功能。这些支撑模块同样需要位于platform-system模块中的人员、组织机构等实体和服务，因此依赖于platform-system。

platform-entityconfig属于低代码配置范畴，定义了业务实体的元数据，通过模块、实体、模型、视图多级配置，结合模板技术，实现细粒度的代码生成控制。

platform-boot-starter：平台启动项目，整合平台基础功能，类似于spring-boot-starter，业务系统引入该包进行依赖。该模块自身没有实体与服务，而是汇总整合，把platform-framework引用进来，同时进行配置。配置分两方面，一方面是做一个配置类，加一些注解（如：@EnableRetry、@ServletComponentScan、@EnableTransactionManagement），使用开发平台实现的业务系统，就不需要在启动类上重复添加这些注解；另一方面，是位于yml配置文件中的配置信息，也分为两部分，一部分是三方组件自身的，如数据源、连接池、redis、quartz、logback，另一方面是自定义的系统参数，如用户默认密码、导出excel数据的批次最大行数量。

platform-boot-starter-demo：示例项目，实际是模拟业务系统如何使用开发平台，用于平台自身功能开发与调试。

能力扩展模块

绿色标示的四个模块，比较好理解，通常是对第三方组件的封装与整合，依赖于公共基础模块platform-common，这些模块可以不断扩展的，业务系统按需引入即可，这样就实现了核心模块必选、扩展模块可选的目的。
platform-boot-starter-mail：邮件，集成springmail组件，实现邮件的发送功能封装
platform-boot-starter-oss： 对象存储，用于文件存储封装，底层可基于多种模式，如本地磁盘、对象存储系统等
platform-boot-starter-scheduler：任务调度，集成quartz组件，实现任务调度可视化配置
platform-boot-starter-notification：消息通知，基于netty实现的websocket，用于系统内置消息

对于扩展模块，平台的核心模块实际也可能会用到，例如platform-support中的附件功能，就会用到platform-boot-starter-oss；platform-system中的自动解锁用户功能，就会用到platform-boot-starter-scheduler。

接口平台

之前开源了一套通用接口平台，详见专栏https://blog.csdn.net/seawaving/category_11610162.html。
现在，将通用接口平台作为一个模块，整合到新的应用开发平台当中来，由通用接口平台统一对外暴露应用系统的API数据接口，以及推送事件消息。
之前的的通用接口平台，主要由两个模块组成，一个是platform-cip（cip是common interface platform缩写），即接口平台的主体，另外一个是platform-cip-common，被platform-cip依赖。
实际上，接口平台的主体，platform-cip，里面包含了三块内容：
1.对外提供API数据接口，提供API服务
2.基于netty的web socket服务端提供消息服务
3.平台自身基础数据的维护，如应用、API服务清单、消息服务清单、订阅等。
本次整合，不是简单的迁移，而是包括重构优化，将platform-cip进一步拆分为三个模块，一共4个模块：
platform-cip-common：公共基础
platform-cip-api：API服务
platform-cip-message：消息服务
platform-cip-manage：平台管理
4个模块内关系为manage依赖common，api和manage相互独立，但都依赖于manage。

前端升级改造

首先是vue2.x升级vue3.x，变化最大的其实是v-model进行了调整，如下：
用于自定义组件时，v-model prop 和事件默认名称已更改：

• prop：value -> modelValue；
• 事件：input -> update:modelValue；

几乎所有的自己封装的自定义组件，都要进行相应调整。

此外，vue3兼容了原来的选项式API，新增了组合式API。虽然组合式API更简练，可以将相关的内容集中放在一起，避免来回拖动滚动条，但实际体验不咋样，特别是一些功能组件太随意，相关内容分散到了整个文件各个地方，修改的时候反而需要通过搜索功能才能定位，个人认为不如vue2的选项式API风格，直接去固定的块里找就好了。

其次是element ui升级element plus。总体来说，这块也还好，大部分沿用了旧版本的属性、方法和事件，个别需要调整，工作量还好，印象中涉及到插槽slot的较多，不做相应调整直接就会报错无法正常显示。

最后是vue-element-admin升级vue-element-plus-admin，这块变化挺大。实际上最主要的一点是，这两个都是前端框架，跟后端整合，需要做大量改造，包括登录、获取菜单和路由、会话失效处理、自动附加token等等。
此外，框架附带了部分封装的组件，实际使用过程中发现，比element plus原生组件更好用一点，但同时封装过程中也把部分element plus原生组件的属性、事件和方法给移除掉了，从而影响到了灵活性和扩展性，因此建议慎用。

实际最麻烦的一块，是第三方组件，或者说是vue3的生态。vue3是2020年9月发布的，到现在都快三年了，第三方组件，普遍面临没支持或支持不足的局面，比较尴尬，如前端文件上传组件vue-simple-uploader、v-charts等，自己动手改造和适配难度不小，工作量很大。

未来规划

客观地说，目前开发平台已经实现了大部分常用常见功能，可以投入使用了。由于是一路狂奔模式，速度提升，时间缩短，但不可避免一些功能遗留了待办项，以及未充分测试导致存在bug，后面需要再循着功能过一遍，进行重构、测试，完善功能，输出设计。特别是低代码配置部分，需要持续完善与改进，简化配置，进一步提升开发效率。

后面几块是平台欠缺的，需要补全和完善，每一块都是硬骨头，难度和工作量都不小，做了一些简单初步的了解，具体如下：

集成图表组件

图表展现能力是平台需具备的基础能力，目前echarts是最佳选择。
在早期版本的百度图表中，不同的图表样式，需要不同的数据格式，需要进行复杂封装才能易于使用。百度官方也意识到这个问题，在echarts 4.0版本提供了dataset属性支持，提供了统一的数据格式，也曾考虑基于这一新特性将常用图表进行封装。
后来，发现了饿了么团队出品的开源组件v-charts，统一提供了一种对前后端都友好的数据格式，只需设置简单的配置项，便可轻松生成常见的图表。
但v-charts停留在了vue2.x版本，vue3.x完全没有动静。百度官方自己出了vue-echarts，待进一步做技术预研后集成。

集成工作流

2021年左右，选择了activiti的分支comunda。当时的情况是activiti主分支已落寞，在comunda和flowable这两个分支中选择了前者。集成原生工作流引擎工作量很大，当时投入了几个月，实现了主要功能，效果不是很满意。
简单看了下近况，市面上最多的依旧是基于comunda或flowable进行的二开。
看好国产自研的济南驰骋的JFlow，

表单可视化

虽然平台自身实现的低代码配置部分，可以配置生成前端vue页面，但表单客户端配置这块，对于非标准化的复杂表单，依旧有价值，特别是对于工作流流程中携带的表单的配置。市面上有些表单配置组件，如form-generator，纯前端，跟后端难以集成与整合，实用性有限。比较看好的模式是FormMaking，有接口来集成后端数据，基于vue3和element plus组件，可惜的是需要商务授权。
还有一个方向是上文提到的驰骋JFlow也附带了表单可视化设计，或许能一起解决，还省了自定义表单和流程的集成工作，待进一步了解和评估。

移动端实现

uni-app，无可争议的多端开发框架，vue开发语言和微信api的组合，巧妙而强大，生态已经做起来了。
这块技术难度一般，工作量比较大。

自定义查询

允许用户自己配置查询条件，单表查询比较容易实现，多表连接查询难度大。

实现数据权限

数据权限是一个非常复杂的问题，如何兼顾灵活性和性能的情况下落地，难度很大。目前市面上很多所谓的数据权限实际没有真正实现，要么是预设了组织机构单一维度，给角色设置只看本部门等所谓的数据权限，首先方向就错了，真正的数据权限控制，应该是给要控制的对象设置权限控制策略。
虽然业务系统对于数据权限的控制需求，或者说控制维度是多种多样的，很难标准化，但是还是有一些常用的。
首先，组织机构是最常见，使用频率最高的一个的控制维度。对于一个集团公司，北京分公司与上海分公司，业务数据在公司范围内可见；公司内部不同部门，如采购部门和销售部门，业务数据在部门内范围内可见。
其次，角色也是经常会用到的，用于跨组织机构或没有系统内部的数据从属关系，例如，公司的几个高管，每人分管几个部门，某个高管，跟分管的部门之间从系统看是没有关联的，但客观又存在业务上的需要，高管能看到自己分管的部门数据。
再次，是与当前用户相关，如要求只有发帖人才能修改帖子内容。
最后，就是跟业务实体的具体属性相关了，例如，业务类型是采购还是销售，配送方式是自提还是送到，合同金额超过100万等。
需要注意的是，以上各维度不是单选，而是存在组合情况。

此外，还需要输出平台使用手册，没有文档的平台，做得再好，也是难以熟悉和使用的。

开发平台资料

平台名称：一二三开发平台
简介： 企业级通用开发平台
设计资料：csdn专栏
开源地址：Gitee
开源协议：MIT
开源不易，欢迎收藏、点赞、评论。