# 数据规范
# 概述
传统的各微服务和应用之间，并没有明确的数据关系和数据定义，导致各应用之间的数据是相互独立的，彼此之间并没有共同的联系。
为了更好地使应用之间能够藕合，数据、应用、平台三者能相互分离，所以在上架应用时（尤其是与核心业务应用相关）必须要遵守数据的一致性，从而才能真正地形成大数据，以及与其他业务之间的协同。
由于数据积累和迁移对于用户是有着重要的价值，中心鼓励每个应用的首个开发的厂商制定数据规范和业务组件（并提供功能代码、文档、测试代码），由中心审核后发布规则，并维护良性竞争。严格禁止利用先发优势，阻断后来者参与竞争。
# 数据规范层次描述
上架的应用，根据应用的范围，对数据规范的要求也有所不同。具体分为四个层级：
第一个层级（数据通用层）：使用相同的枚举字典，使数据之间的含义保持一致，所有上架应用必须遵守。
第二个层级（数据共享层）：应用的主数据（比如：报表数据、大仪数据）的定义，都存储在元数据中，相关应用要随着主数据（元数据）的改变，而自动改变。鼓励上架应用业务组件及业务组件代码的贡献和发布，谁先做就以此为基线，进行不断地迭代完善，从而形成成熟的业务组件，最终目标是相同应用之间切换在用户使用层面无感知，让用户有权来选择最好的应用。
第三个层级（资产关联业务层）：应用的数据与资产的数据有关联，他们定义的信息项中必须要有gs1的信息项内容（比如房产、大仪数据），平台查询相应资产卡片gs1信息的接口；若卡片不存在，则平台需要提供生成卡片并获取gs1信息的接口，这样才能与资产信息进行相对应，如没对应上，后续是无法进行修补的。这个层级，要求与资产相关的业务应用都必须遵守。
第四个层级（资产业务层）：目前系统中有领域业务建模，以及相应的公共领域微服务。这个层次，要求资产应用必须遵守领域业务建模的领域微服务。
# 数据通用层
# 枚举字典查看
# 查看方式
开发公司申请开通开发租户，并申请加入云应用管理平台的租户。
协同中心审批通过后，开发租户登录进去后，进入平台管理—配置管理—字典管理进行查看。
# 计划改进
开发公司在上架应用(开发者中心)的时候，就能进行相应的查看。
以及在资产云开放协同创新中心的租户中，能以字典查看方式进行查看。
# 新枚举字典申请
发现缺失内容：开发公司根据目前平台中的字典内容，如发现在上架应用中还需要新的枚举字典，或者枚举字典项。
提出申请：向协同中心提出相应的单据申请，包括新增或者调整的枚举字典和枚举字典项的内容。
申请应该参考国标、地标和行业标准，并论证其字典符合标准，经中心评审后发布为准。
# 新枚举字典批复
由协同中心进行。
# 建议的技术方式
1、通过消息SDK，接收到消息后应用自身进行相应的适应性调整。
2、协同中心每周通过内部公告形式通知所有开发租户。
# 验证及审核
上架应用时，各应用应说明和填写，系统中应用了那些枚举字典项及内容；
协同中心进行抽查。如发现不符合项，则进行预警，写明具体不符合规范原因和说明，给予相关服务提供厂商15天的整改时间，如果仍然没有完成整改，则将应用进行下架，直至整改完成后才能上架。
# 数据共享层
# 业务组件
业务组件指的是基于业务规则所总结出的API、权限、以及对数据库的操作；是其对于业务需求的代码封装和抽象。这些代码或者API可以便于后续其他同类公司所调用。
相同业务的应用应该优先复用已有业务组件，以降低用户数据迁移成本。如对已有业务组件使用有技术疑问，请联系中心。
开发公司在开发新应用时，如发现可以抽象并贡献业务组件时，鼓励把业务组件的代码、文档、测试代码提交到gitee的公共代码中。
对于新提供的业务组件，不应该影响现有客户的正常使用；或者给与各厂商和用户足够的调整时间。
业务组件需提供每个接口 API 文档说明（包括不限于各参数说明、返回值说明，副作用说明），以及每个 API 单元测试代码。
# 验证及审核
上架应用时，各应用应说明和填写，系统中应用了那些元数据项及内容；
协同中心进行抽查。
# 资产关联业务层
# 资产范围内容查看
资产范围包括资产的属性（房产、公车、大仪等）、资产的分类（资产类别）、资产的使用属性（教学、办公）、资产是否共享、资产的单位属性、资产的区划属性等；
资产相关业务开发的厂商，可以通过元数据和枚举字典——资产部分进行查看资产的属性。
# 关联的资产范围申请
如在资产相关业务中需要相关的信息数据，由开发商向协同中心提出申请；
协同中心接到申请单据后，检查是否符合要求，如符合，则审批通过；如不符合，则写明原因后驳回。
开发商通过平台接口进行开发调试。
# 上架申请
资产相关业务厂商在上架前，需要提供相应的数据规范测试报告，确保资产相关业务主数据中有gs1唯一编码，才能进行上架申请；
协同中心人员进行上架的审核。
测试报告包括：用户使用报告，第三方功能测试报告，第三方压力测试报告和第三方安全测试报告。
# 验证及审核
上架应用时，各应用应需提交测试报告；
上架后，协同中心人员可以进行抽查；
# 资产业务层
# 公共业务组件查看
开发资产业务的厂商，为便于技术开发，请向中心申请后，加入到gitee的开发组织中；
加入后，可以查看后台资产公共业务组件（具体在blade-service的asset-card里）；
熟悉里面的公共业务组件，以及相关的方法。
# 公共业务组件改进（可选）
进行公共业务组件的测试，确保系统调用业务接口来访问统一卡片库。
进行公共业务组件的测试，确保卡片库数据对业务动作的一致性。
联调成功后，则由资产业务开发厂商出具联调报告。
# 系统切换的测试报告要求
申请资产业务开发的厂商，资产系统开发完成后，与目前的资产系统进行系统切换测试。
测试关键环节：
新开发的应用中发生相关业务操作后，是否基于平台统一卡片库（mongodb），并检查是数据是否存在丢失或错误。
平台相关资产业务发生时，是否访问平台统一卡片库均通过平台提供的方法，并检查系统之间是否能随意切换使用。
如能进行系统之间能随意切换使用，由业务厂商出具测试报告，提交给协同中心；
# 上架申请
新开发资产业务的厂商在上架前，需要提供相应的测试报告（包括测试报告、系统测试报告），才能进行上架申请；
协同中心人员进行上架的审核，是否属实和符合要求。
# 验证及审核
上架应用时，应用需提交业务组测试报告和系统切换测试报告；
协同中心可以进行抽查
测试报告包括：用户使用报告，第三方功能测试报告，第三方压力测试报告和第三方安全测试报告。
# 附录：
# 数据主键定义
主键类型：Bigint(20)
雪花算法生成
# 数据删除逻辑
实体表：软删除；
关系表：硬删除
# 数据删除标识
is_deleted：0->有效；1->被删除；
# 数据状态标识
业务状态标识status：默认1->有效；0->无效；可根据具体需求进行自定义；
自定义的业务状态标识规定从100开始定义；
# 数据库审计字段
| 字段名称 | 含义 | 数据类型 |
|---|---|---|
| create_user | 创建用户 | bigint(20) |
| update_user | 更新用户 | bigint(20) |
| create_time | 创建时间 | datetime |
| update_time | 更新时间 | datetime |
# 图片存储逻辑
图片、音频等资源类数据采用OSS方式存储，存储完成后返回资源路径进行存储；
# 用户头像存储
字段类型：varchar(255)
# 枚举字典引用
统一采用字典表（as_dict）id值进行枚举字典关联。
避免枚举字典相关的敏感操作（如删除）。
# 用户跨租户逻辑设计
同一用户属于多个租户的情况，默认为多个租户生成该用户数据的副本（需要定义主从关系）。
# 多租户设计
应用管理平台属于多租户系统，采用单库单表的隔离方案，所有实体表都需要增加tenant_code以实现多租户之间的数据隔离。
# 租户类型关系维护
租户类型由枚举字典统一定义。通过as_tenant_attr_role表定义租户类型与角色之间的关联关系。
# 其它
# 考虑国际化
- 手机号码存储方式变更：国际码-号码主体（国际码+"-"+号码主体）；数据类型：varchar（20）
TODO