开发规范
后端规范
模块化开发
应用基于springcloud微服务架构，所以业务开发模块需要放在incloud-base-biz模块下； 具体模块划分说明见【模块说明】
模块命名
如果为多层maven模块，子模块命名遵守A-B-C-D...形式，分隔线使用-，每个单词代表项目、二级分类、三级分级...业务子模块名称。
多层maven模块，子模块的目录层级也同时遵守子模块名称递归目录结构，如子模块名称为：A-B-C，则其目录结构为A/A-B/A-B-C结构。 这么做的目的，一方面是直接从名称上可以直接推断出其属于哪个业务的模块，同时也能直接推荐出其在整个工程里的目录层级， 方便对其进行运维，如自动化构建，做自动化脚本处理等，因为其有规律性，方便维护，有规则的才是规范的嘛。
尽量使用英文单词，并且小写，方便阅读。
平台包命名规范
包名遵循 域名+公司名+一级模块名+二级模块名+功能实现命名 根据实现业务进行包名扩展，要求简洁明了， 如：com.netwisd.base.file
标准化包命名结构如下：
config #配置类
constants #常量
controller #控制层
dto #业务请求数据封装
entity #业务实体——对应数据库表
feign #feign调用
index #全文检索的索引类配置——如果需要做的话
mapper #mybatis的mapper类
msg #消息相关类——如果需要的话
service #逻辑接口层
service.impl #逻辑实现层
util #工具类
vo #数据展示实体类
数据库表名规范
数据库表名结构为：
incloud_moduleName_subModuleName_bizTableName
例：
incloud_base_dict_encond_rule
incloud_base_wf_process_log
incloud_base_wf_event_param_def、
即：incloud + 一级模块名 + 二级子模块名 + 业务表名的形式；
表为全部书写为小写，便于阅读；
每个单词间使用 “_” 下划线连接；
单词起名为有意思的英文单词名，便于理解；
过长的表名，使用单词缩写
类命名规范
类名必须使用有意义的名字；
类名的每个单词的首字母必须大写—帕斯卡命名法；
类名不能使用数字 除了_和
123这个命名是正确的命名，但是它没有使用的意义，所以不建议使用这个的命名，作为程序员的备选人应该严格遵守，命名规则，使用有意义的命名。 建议用英语、实在不会就用中文，记住是帕斯卡命名法，每个单词首字母需要大写 如：MobileCard 翻译是手机卡 中文：ShouJiKa 这种是帕斯卡命名法
接口调用约定
接口调用使用feignclient调用如：下面调用incloud-base-msg服务1@FeignClient("incloud-base-msg")
调用方如果有全局分布式事务需求，请使用seata
调用需要处理被调用方可能抛出的异常，需要进行try处理，之后进行日志处理或再次throw处理；
前端开发规范
目录结构规范
项目业务开发放在src下，src下第一级目录为各个功能页面文件夹。
功能页面文件夹下标准化目录结构如下：
main.ts 页面构建入口，引入全局组件，全局样式等设置
App.vue 主页面，写入业务代码，组件引用等逻辑
api.ts 请求接口设置，业务所用到的接口请求命名文件
components 局部组件文件夹，声明组件放在此文件夹下
命名规范
目录命名
全部采用小写方式， 以中划线分隔，有复数结构时，要采用复数命名法， 缩写不用复数。 components 中的组件目录，使用 kebab-case命名。 components 组件目录外的所有目录也使用 kebab-case命名。
JS、CSS、SCSS、HTML、PNG 文件命名
全部采用小写方式， 以中划线分隔。
命名严谨性
代码中的命名严禁使用拼音与英文混合的方式，更不允许直接使用中文的方式。 说明：正确的 英文拼写和语法可以让阅读者易于理解，避免歧义。注意，即使纯拼音命名方式也要避免采用
Vue Template 规范
缩进
缩进使用 2 个空格（一个 tab）； 嵌套的节点应该缩进。
分块注释
在每一个块状元素，列表元素和表格元素后，加上一对 HTML 注释。
标签语义化
组件命名尽量使用英文语义化命名，做到见文知意。
css规范
类名使用小写字母，以中划线分隔
id 采用驼峰式命名
less 中的变量、函数、混合、placeholder 采用驼峰式命名
和 class 的名称总是使用可以反应元素目的和用途的名称，或其他通用的名称，代替表象和 晦涩难懂的名称。
css 选择器中避免使用标签名
使用直接子选择器
尽量使用缩写属性