关于产品设计的一些思路

admin

解决大流量、高并发诉求。


前端思路：


前端oss/cdn分发。

用户API 调度清单。



后端思路：APIAddress

基于角色的API地址 分配策略

基于用户物理位置的分配策略

基于用户的性别分配策略

基于用户名拼音首字母排序的分配策略

基于用户哈希值取模的分配策略  

admin

机密性设计：


访问控制{MAC 控制、DAC自主、RBAC 角色}


数据权限： 授权的权限{基础具备：读权限&分配权限。 可分配： 写、读权限。}、查看的权限{读权限}、写权限{}。

备注： 常规的信息化系统、仅通过rbac + 数据权限（行） 权限分配用户权限功能。

我认为：如果是个人自己的数据、在数据表行没有数据机密性列权重的时候。  用户有权利自助分配已经创建的数据让别人看。

这种需求在crm 系统内十分常见。

这种需求如果利用 申请 发送邮件的方式。 容易因数据时效性问题导致数据不一致。

在做代码生成器的时候，有必要按需提供     数据授权列表页、数据授权页面的   相关代码、sql 数据表装卸与视图的生成。


信息流

完整性：Biba、Clark-Wilson

admin

认证与授权两项基本功能:

鉴别服务：{认证机制、数字签名机制}

访问控制服务：  访问控制机制、路由控制。


数据机密性服务：{加密机制、业务流填充机制}


数据完整性服务：数据完整性机制  

admin

租户：


树形租户模式。

admin

租户：


树形租户模式。

admin

spring mybatis 会校验 启动时 mapping 与 数据库内的配置。


（1）mapping 提供缺省配置，entity层追加自定义的注解实现映射关系与缺省配置。

（2）代码生成器功能中表设计中包含在db mapping映射的缺省配置。

         依据数据库缺省配置，动态生成dao 缺省的代码， mybatis 内的xml 无代码，但是可以覆盖缺省。
        


          数据库中实现动态配置。动态配置数据权限相关内容。   全在线配置式 缺省增删改查模式。


          对缺省增删改查，均为动态redis 缓存字符串。  每个线程均能自定义再加工查询语句。


弊端： 安全性。

解决方案：

开发模式、测试模式、生产模式。


在生产模式中，代码生成器功能无法使用，仅有开发者、系统维护人员才能更改相关配置信息。



系统启动问题：

预设性：  缺省直连、h2内存、redis 缓存。

admin

项目安装时，应该有版本信息摘要的输入框。

安装完成后，应该有能力记录版本号，升级日志， 升级，回滚，回退。 自动备份等功能。

首次安装判断字段。。根据首次安装，是否提示社区测试数据脚本执行的功能。

admin

admin 发表于 2023-10-27 14:30
（1）mapping 提供缺省配置，entity层追加自定义的注解实现映射关系与缺省配置。

（2）代码生成器功能中 ...

1. 这个问题缺点在于。
   
2. 
   
3. （1）项目启动初期 将数据库配置加载到 内存，需要时间。增加了软件加载周期。
   
4. （2）实现在线安装软件功能变得复杂。
   
5. （3）启动程序要分阶段启动。 分为系统表载入[同步-启动的最小代价]、非系统表载入[完整性、全功能可用]。
   
6. （4）存在安全性风险，这种在线的coding，使得运营人员具有了开发者的破坏力。
   
7. （5）优点是：代码更简洁、优雅。在配置化过程生成缺省代码。

复制代码

admin

在线校验功能的支撑

前端校验能力，可基于在线能力动态 js-to-oss 追加。

admin

基于构建的开发。

controller  每个接口要具备： 链请求接口。

preRequest/NextRequest能力。 或者  顶部|底部。

这样就能够实现 controller 接口功能的在线可视化组合能力。

设计时要考虑好：事务的传播行为、事务隔离级别。

详情参考：C2 架构风格。



这种情况：

要考虑线程id的记录、流程ids、等等。