产品领域的元宇宙椅子套罩图片及价格( 三 ) _业务

1）规则引擎
类似上面提到的，字段校验、过滤、表单引用联动等，如果可选、必填；字段长度、格式；是否引用关联这些都可配置，大量的基础硬编码工作将被aPaaS取代，研发工程师可以一劳永逸。
2）流程引擎
处理静态规则之外的，当系统发生交互后的流程处理，包括各类触发和执行、通知反馈。比如当用户拨打电话后，记录一次跟进，同时给TA的主管推送一条消息。这样的流程其实抽象出来后，就是“触发”“编排”和“执行”“反馈” ，是可以像画流程图一样配置出来的。
3）权限引擎
SaaS理解为独立单个系统，往往有角色控制即可满足，而aPaaS可以理解为跨系统复杂模型，不但要管控系统内的功能、应用，还得对meta层、读写权限进行管控。
比如当A工程师是“线索”实体owner时，一旦“线索”实体增加了一个不可操作的字段，也许是一个全新的、不被之前权限定义的字段，这时就需要对这个对象记录的权限进行管控，此时就需要引入对象、记录等权限，只靠角色和数据表的权限，就不够用了。综上，通过对规则、流程、权限进行配置化处理，能够让软件的主干业务逻辑部分支持配置化，是aPaaS的核心能力之一。
三、aPaaS设计干货实例-权限设计上面讲了很多原理、方法、总结。这部分想用一个实例来让文章更直观完整。我想用“权限”这个模块来作为实例。权限模块，在传统SaaS中，其实并不算复杂。一般一个产品经理半个人力就能cover住，只需要注意用户A是否能用某系统，是否能查看某些数据、是否有编辑等功能权限即可。但在aPaaS中，如上所说，已经不仅仅是一个SaaS的权限问题，而是多个错综复杂的SaaS权限问题。
关键在于比SaaS来说， aPaaS核心的两大能力：低代码灵活配置和打破数据孤岛，这决定了从产品上来说，一定会存在大量的元数据定义和大量的租户，这样一来，权限系统就会成倍复杂。但无需担心，可以直接用类比SaaS的方式进行产品设计。
从数据实体来说，因为引入了object ，就需要对这个维度进行权限管控。object意味着某些字段对于用户来说是否可用，这往往是根据角色来决定的。比如行政可以看到每把椅子的采购价格和实付价格，而普通员工却不关心也不应该看到“椅子采购系统” 。
data层面，也要有记录维度的管控。比如对于薪酬hr来说，应该可以看到员工的薪资，而普通员工只能看到自己的薪酬，其区别不在于“薪酬”这个字段，而在于“别人的”“自己的” ，所以并不是object层面的管控，而是data的record层面管控。
如上， object其实决定了领域，一个领域应该有一个对应的profile ，比如采购人员应该负责采购相关系统，所以需要一个采购profile 。如果采购人员同时兼任HR ，那么也应该具有HR的profile 。profile背后，是对一些实体、对象甚至系统的权限，可以和业务、事业领域做类似的映射。
在data层面，往往是记录（record）的权限。比如“椅子采购系统”的超级管理员应该可以看到并修改全部“椅子实体”数据，而采购助理可能只能查看、编辑自己提交的记录，不能编辑别人创建的的“椅子采购记录” ，这就是record级别的管控，一般是用于区分业务内的不同岗位、角色。所以对于aPaaS的权限系统来说，至少要设计2个层次的权限：