# 工程脚手架构生成
# 工程示例
系统应用集成示例工程打开 (opens new window)
# 概述
工程依赖于六边型思想，整合当前的项目工程结构特点，进行的规划和划分，以下为整体工程的规划架构：
# 本内容你将获得
- 工程脚手架的工程结构
- 每个工程模块的职责
- 工程的后期的升级思路
- 生成基础平台字段
# 脚手架的生成说明
与工程规范略有出入，主要是因为历史升级的原因
工程脚手架基于多边型思想，并结合实际行业的 mvc 模式， 以最小的成本切入最新的灵活的架构，整合的思路， 这里主要是面向接口编程
# 工程脚手架的工程结构
这里的目标是将核心业务与其它的非核心业务分开，避免污染核心业务逻辑，如果分得再细一些， dao 层也可单独抽出，这里不抽出的原因是工程结构偏向中小企业，以 mysql 为主
<!-- 接口包 -->
<module>alinesno-cloud-shop-manage-api</module>
<!-- 核心业务包 -->
<module>alinesno-cloud-shop-manage-domain</module>
<!--
历史非前后端遗留包
<module>alinesno-cloud-shop-manage-web</module>
-->
<!-- 对外接口服务包 -->
<module>alinesno-cloud-shop-manage-gateway</module>
<!-- 启动包 -->
<module>alinesno-cloud-shop-manage-boot</module>
<!-- 前端工程包 -->
<module>alinesno-cloud-shop-manage-ui</module>
# 每个工程模块的职责
每个模块职责详细说明：
- 接口包(api): 这里是一切面向接口编程，这里放置公共的非实现组件，主要用于第三方依赖，最小包的依赖，避免污染第三工程。
- 核心业务包(domain)：这里主要包含核心的业务落地，目标是达到可依赖，可单独跑，包含核心价值，颗粒度以实际架构设计为主
- 对外接口包(gateway)：这里不依赖核心业务落地包，目标是加入新的服务实现(dubbo/rpc/mq/rest)不影响核心包
- 启动包(boot)：这里主要用于工程配置，目标是只处理配置整合，这里可包含业务覆盖最小业务逻辑
- 前端包(ui)：对核心模板的管理，目标是对业务的最小逻辑管理，也仅管理此业务，面向 gateway 和 api 编程
工程包结构为保留最核心的业务落地，同时避免各个污染。
# 生成平台基础字段
这里主要包括平台的一些默认字段，包含通用的平台字段，用于整体平台的考虑，主要包括如下：
//////////////////////////////// 通用应用字段 ///////////////////////
private String id; // 唯一ID号
private String fieldProp; // 字段属性
private Date addTime; // 添加时间
private Date deleteTime; // 删除时间
private Date updateTime; // 更新时间
private int hasDelete = HasDeleteEnums.LEGAL.value; // 是否删除(1删除|0正常|null正常)
private int hasStatus; // = HasStatusEnums.LEGAL.value ; // 状态(0启用|1禁用)
private String deleteManager; // 删除的人
private String lastUpdateOperatorId; // 最后更新操作员 用户权限: 只能看到自己操作的数据
//////////////////////////////// 数据权限规划 _start ///////////////////////
private String applicationId; // 所属应用 应用权限: 只能看到所属应用的权限【默认】
private String applicationName; // 应用名称，唯一性，用于做应用标识【最好与springboot的applicaiotn.name对应】
private String tenantId = "0"; // 所属租户 , 租户权限
private String operatorId; // 操作员 用户权限: 只能看到自己操作的数据
private String fieldId; // 字段权限：部分字段权限无法加密或者不显示，或者大于某个值
private String departmentId; // 部门权限: 只能看到自己所在部门的数据
/////////////////////////////// 数据权限规划 _end ///////////////////////
基类字段说明：
- 自定义基础字段，自定义基类即可，自定义基类的话，会有一部分方法不可用，根据特定业务重写即可
- 类似的场景主要是一些特殊的业务表，要求高的性能表等，此类表占系统部分较少，特殊业务特殊处理。
在代码工程类中，已集成自动生成CheckEvn.java类，在boot模块下面，打开注释运行即可自动生成基础字段。
# 工程的后期的升级思路
这里升级包括核心业务逻辑的升级，技术的升级，前端的升级，其它升级再讨论，其中如下：
- 业务落地升级：使用打补丁的方式，比如增加新的模块持续集成模块，则添加
-cicd模块，同时在 boot 启动工程中集成 - 技术升级：由 rest 接口转成 grpc，则调整 gateway，不污染 domain 工程
- 前端升级：直接调整，同时切换即可
# 升级指导示例
这里只列出通用的，提供对应的思路，复杂场景单独讨论，这里非绝对
# 场景 1：核心包需要调用其它的服务
方案：添加 consumer 模块，在 consumer 中提供出集成，在接口包中提供接口，实现在 consumer 中，由内部其它其它包调用，这里 consumer 可依赖多可第三方 sdk，具体可查看工程规划查看
# 场景 2：添加 ELK 日志监控
方法：在 boot 中集成日志服务组件，有必要相关包需要提供出业务日志的相关输出能力
# 场景 3：对外提供 sdk 服务
方案：添加 sdk 模块，调用 gateway 接口服务
# 场景 4：新人开发新核心功能
方案：核心包由业务高级工程师维护，新核心模块依赖 api 包，新人实现新的核心业务逻辑模块，稳定之后，再考虑是否有必要集成到核心包(也可不集成)，在 boot 包中依赖启动
# 其它
- 无