# 基于EOS8的开发集成规范说明
# 版本号
版本号采用3位和4位两种情况：
- 产品（如主数据、ESB），使用3位号，示例：8.2.1
- 组件（独立发布，一般发布节奏比较快，如AFCenter），使用4位号，示例：8.2.1.1
# 发布介质
# 制品形态
产品最多可提供4种形态的介质，分别面向不同的场景：
- express版本：这是产品的最精简形态，目标是让用户下载后，直接启动就可以使用，目前只有EOS提供此版本，EOS express版本解压即可运行，运行期只需要数据库（无需nginx、redis、网关等），内置了包括AFCenter、BFP、Lowcode的能力。其他产品默认不需要提供此版本形态的发布介质。
- standalone版本：这是产品的标准形态，standalone版本前后端分离，但是不需要云原生服务（如nacos、网关等）的运行支撑。目前基于EOS开发的各产品，都需要提供这个形态的介质，默认将AFCenter能力打入到自己的前后端中，运行时依赖nginx、redis、数据库以及产品自身需要的服务即可。
- microapp版本：这是在用户已有EOS8的标准云原生环境后，如果再购买基于EOS8研发的某个产品或组件时，提供的该产品或组件的独立微服务的介质形态，microapp版本是无法独立的，往往用于组件独立迭代，最终联合构建大型解决方案的场景。
- full版本：这个是复杂产品的全量服务单机安装形态，目前只有EOS存在这个版本形态，将云原生所有服务进行打包在一起，最终一键启动运行。其他产品默认不需要提供此版本形态的发布介质。
下表是各个基于EOS8研发的产品介质形态建议：
| 产品 | 介质形态 |
|---|---|
| EOS | express、full |
| BPS | standalone |
| ESB | standalone、microrapp |
| 主数据 | standalone、microrapp |
| 数据质量 | standalone、microrapp |
| 数据资产 | standalone、microrapp |
| 数据开发 | standalone、microrapp |
| 数据建模 | microrapp |
# 二方库发布位置
- 所有产品，日常编译时，都需要将二方库提交到内部nexus仓库中
- 如果产品在外部有集成或定制要求，建议在发布时将二方库同时提交到内部nexus仓库和阿里云公网仓库中
# 配置文件
这里的配置文件主要是指application.properties相关文件，这个在eos、bps、mdm等产品中已经按规范做过整理，具体文件分割和文件里的内容要按规范严格执行。
文件切割方式，按产品和组件切割，拿两个产品为例：
EOS express版本
- application.properties，存放eos的基础配置，springcloud的原生配置，这里面通过spring.profiles.active来激活需要使用的配置文件（nacos、afc、bps）
- bootstrap.properties，特别处理nacos的配置中心能力
- application-nacos.properties，nacos注册中心相关配置
- application-afc.properties，afcenter程序需要的配置
- application-bps.properties，bps程序需要的配置
主数据 standalone版本
- application.properties
- bootstrap.properties
- application-nacos.properties
- application-afc.properties
- application-mdm.properties，主数据特有的配置（要包括了一些原生的springcloud配置，主要原因是主数据里用了不少原生springcloud能力，如JPA等）
# 初始化脚本
当产品使用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方式，可将一些缺陷或优化，不断合并到定制项目前端分支中。