基于EOS8的开发集成规范说明

# 基于EOS8的开发集成规范说明

版本号采用3位和4位两种情况：

产品最多可提供4种形态的介质，分别面向不同的场景：

express版本：这是产品的最精简形态，目标是让用户下载后，直接启动就可以使用，目前只有EOS提供此版本，EOS express版本解压即可运行，运行期只需要数据库（无需nginx、redis、网关等），内置了包括AFCenter、BFP、Lowcode的能力。其他产品默认不需要提供此版本形态的发布介质。
standalone版本：这是产品的标准形态，standalone版本前后端分离，但是不需要云原生服务（如nacos、网关等）的运行支撑。目前基于EOS开发的各产品，都需要提供这个形态的介质，默认将AFCenter能力打入到自己的前后端中，运行时依赖nginx、redis、数据库以及产品自身需要的服务即可。
microapp版本：这是在用户已有EOS8的标准云原生环境后，如果再购买基于EOS8研发的某个产品或组件时，提供的该产品或组件的独立微服务的介质形态，microapp版本是无法独立的，往往用于组件独立迭代，最终联合构建大型解决方案的场景。
full版本：这个是复杂产品的全量服务单机安装形态，目前只有EOS存在这个版本形态，将云原生所有服务进行打包在一起，最终一键启动运行。其他产品默认不需要提供此版本形态的发布介质。

下表是各个基于EOS8研发的产品介质形态建议：

这里的配置文件主要是指application.properties相关文件，这个在eos、bps、mdm等产品中已经按规范做过整理，具体文件分割和文件里的内容要按规范严格执行。

文件切割方式，按产品和组件切割，拿两个产品为例：

当产品使用EOS8开发时，势必会遇到统一数据库脚本管理问题，通常会有两种情况：

standalone版本，需要将依赖的EOS8产品或组件的数据库脚本都打进来（比如eos或afcenter的数据库脚本），同时额外还有自身的相关脚本
microapp版本，除了自身的脚本外，也有可能有一些组件的脚本需要一起管理（比如应用要支持低开能力，就会单独依赖bfp和lowcode，则需要这两个组件的对应脚本）

无论上述哪种情况，在最终数据库脚本打包管理的方法上是一致的，需要在最终的集成项目的pom文件中定义需要打进来的数据库脚本位置，以及最终打包的assembly文件中按组件形成分目录的结构。注意在脚本的执行顺序上，一般将自身的脚本放在最后执行，可用于对依赖组件的脚本的一些局部变更。

下面给出EOS express版本中的最终脚本参考，其中会有一个all目录，是将所有组件的脚本，按不同数据库，合成成一个全量文件的目录，便于用于首次初始化（PS：注意有些产品默认是多个数据库的，则需要按库分开合成不同的全量文件）：

通过代码集成时，一般会分两种标准，一类是内部研发项目的集成标准，一类是外部定制实施的集成标准，之所以这两类项目在开发集成上有区别，主要原因有两个：

一般公司发布的产品，默认会提供两种集成模式，一种是starter模式，一种是sdk模式。在内部研发时，在编写源码项目中（非集成），默认只会依赖sdk（不依赖starter），这样基于源码中boot的构建包，打出来的就是microapp形态的介质。

另外需要再创建一个专门用于打standalone形态的项目，此项目里一般没有任何java代码，只有一个boot包，管理着特有的配置文件等。这个集成项目依赖的是starter，这样最终做到打包时将依赖组件的后端都打入到自身介质中。

对于前端，因为内部都采用了微前端的开发模式，所以产品只需要关注自身的前端开发，最终打出独立的微前端即可。

外部定制项目，后端建议在源码中，直接采用starter模式来集成，非特别原因不用考虑采用microapp的模式。

对于前端，可考虑与产品主干或分支持续同步源码，在独立分支上完成项目定制，这样通过分支合并或cherrypick方式，可将一些缺陷或优化，不断合并到定制项目前端分支中。