SaaS系统框架搭建详解

根据百度百科的解释:“SaaS,是Software-as-a-Service的缩写名称,意思为软件即服务,SaaS平台供应商将应用软件统一部署在自己的服务器上,客户可以根据工作实际需求,向厂商订购所需的应用软件服务,按定购的服务多少和时间长短向厂商支付费用,并通过互联 获得SaaS平台供应商提供的服务”。

SaaS系统能提供一个或者多个行业常见场景的功能支持,并且只要在有 络的前提下具有“随处可用、拿来即用、不用下载”的特点。

对于SaaS服务商来说,边际成本随着客户的增多大幅度降低;对于客户来说,能在业务开展前期先小成本试用,降低软件综合成本,可以更聚焦于业务本身的开展;对于用户来说,可以拿来即用,并且SaaS系统的常规设计符合相对应领域用户的心智模型,使用起来非常方便。

所以现在SaaS系统的流行已然是一种趋势。接下来为大家详细介绍一下SaaS系统的框架搭建,也就是SaaS异于其他常规B端平台的地方—权限的配置以及数据的隔离要更为复杂一些。

一、菜单管理

菜单管理主要是为了管理后台系统菜单的展示、排序、以及跳转,开发人员每次做好新的的功能时,可以直接从这里配置到后台,不需要通过在数据库插数据,或者走开发、发布、上线的流程。

参照原型如下:

  • 标识码:唯一标识,去重
  • 菜单名称:名字直接体现了导航的内容
  • 菜单图标:和菜单名称相对应,只有目录类型和菜单类型的才会有
  • 权限代码:代码里面不会进行汉字逻辑判断,需要设计对应标识码,为后续权限设置提供选项
  • 父级菜单:菜单的层级关系
  • 排序 :控制同一层级的前后顺序
  • url:菜单类型才会有该字段
  • 跳转类型:内部跳转(相对路径)、外部跳转(绝对路径)
  • 跳转方式:原页面打开、新页面打开
  • 类型:目录(可以包含目录和菜单)、菜单(设置跳转url)、按钮(设置权限的最小单位)
  • 状态:开启(正常在导航中显示的菜单)、关闭(停用不在导航中显示的菜单)
  • 二、站点管理

    站点管理主要是为了不同机构的名牌化宣传,专门为机构配置专属域名&名字&logo等。多个机构也可以用同一个域名。不管是否使用不同的域名,不同机构的用户数据都会做数据隔离。

    大概涉及到的字段如下:

  • 组织名称:从已有的组织下拉菜单中进行选择
  • 域名:用户访问的前端 址,后台 址一般在前台 址的后面加上/login
  • 门户 站设置:名称、logo
  • 后台设置:名称、logo
  • 支付相关配置、页尾菜单配置、数据统计配置等其他配置
  • 三、组织管理

    SaaS系统通过组织来实现多租户管理,为租户配置管理员以及系统的功能权限等,除此之外还可以根据实际需求为租户设置可以管理的其他组织以及组织下内容,对于会提供内容服务的SaaS服务商,需要对应设计跨组织共享内容的功能。接下来要给大家分享的SaaS框架支持跨组织管理数据以及跨组织共享内容。

    参照原型如下:

  • 组织名称
  • 管理员信息配置:账 、手机 、密码
  • 系统有效期
  • 后台(or前台)账 数量限制:根据业务需求进行必选项的配置
  • 组织结构:支持多级组织结构(事业部&部门&小组等)
  • 前台模块权限
  • 后台功能权限
  • 组织权限
  • **内容权限(课程包&资讯等)
  • 1. 组织和管理员的关系

    ①管理员默认有该组织的最高功能权限;

    ②管理员默认有管理组织的全部数据权限;

    ③SaaS服务商(原型中的A机构)默认有一个总的管理员账 ,拥有整个系统最高的数据以及功能权限;

    ⑤组织中的管理员账 只在组织模块中出现,不会在账 管理模块中出现;

    2. 系统有效期

    ①系统到了有效期之后,如果机构不续约一般数据还会保留1~3年;

    ②超过有效期之后前端用户一般无法登录;

    ③超过有效期之后后台用户设置为只能查看部分数据,无法操作。如果数据被清空之后也无法登录了;

    3. 前台模块权限

    ①门户 站的功能模块配置;

    ②不配置的模块在前端看不到或者点击提示无权限;

    4. 后台功能权限

    ①配置该组织拥有的后台功能权限;

    ②默认授权给组织管理员功能权限;

    5. 组织权限

    ①分配该组织可以管理的组织以及每个组织对应的模块内容(课程包&资讯&角色&账 等);

    ②默认分配给管理员;

    原型如下:

    6. **内容权限配置(课程包&资讯等)

    ①共享给被操作组织具体的内容,同步共享给管理员一份;

    ②无法共享给自己所在的组织,同组织共享通过账 进行共享,后续在账 管理中会讲到;

    ③跨组织共享是一种复制性的共享,同一个ID的内容可以多次共享,每次共享生成一个新的内容(产生新的ID);

    原型如下:

    原型如下:

    四、角色管理

    具体涉及到的字段如下:

  • 角色名称
  • 组织名称
  • 状态:启用、禁用(禁用后拥有该角色的后台账 所对应的权限随时消失)
  • 五、后台账 管理

    参考原型如下:

  • id
  • 用户名
  • 姓名
  • 手机
  • 密码
  • 创建时间
  • 状态:(启用、禁用、禁用状态的账 无法登录系统)
  • 功能权限
  • 组织权限
  • ***内容权限
  • 1. 功能权限

    ③支持多选;

    2. 组织权限

    3. **内容权限(课程包&资讯等)

    原型如下:

    所以比较规范的操作流程是:内容在进行跨组织分享时同步分享给被操作组织的管理员后,后续再用管理员账 或者其他账 在组织内部进行分享。

    原型如下:

    注:跨组织分享后一个产品相当于被复制成内容一样的另外一个产品,后续的任何更改都不会被同步。而同组织共享之后仍旧是同一个内容,后续任何更改都会同步。

    六、前台账 管理

    前台用户可以在门户 站上看到自己所在组织的有权限的前台模块,如果有场景需求可以精细化同一个组织下的不同前端用户分别设置权限。前端的数据隔离分为两种:

    ①不同的组织发布的内容只能本组织的前台用户可以看到。

    ②对于SaaS服务商为多个租户提供内容服务的业务,可以对其进行特殊化处理,使其发布的内容让所有的组织的前端用户都可以看到,但是不同组织产生的用户内容只能本组织的用户看到。

    前台用户涉及到字段如下:

  • 用户名
  • 姓名
  • 手机
  • 所在组织
  • 注册时间
  • 注册方式:前台注册、后台导入
  • 最近登录时间
  • 状态:启用、禁用(禁用状态的账 无法登录系统)
  • 小结

    常规SaaS系统的设计用到的概念或者思路大概是类似的,但是是否需要进行跨组织管理,跨组织管理需要精细到什么程度。

    不同组织的用户数据、相同组织的用户数据如何隔离,处理方式是否相同等都是要根据实际业务场景来设计的。

    没有完全标准通用的SaaS系统,我们需要设计的并不是一个完美的SaaS,而是一个最大限度符合业务需求,又能在通用的同时兼顾后续长远规划,尽最大可能降本增效、提升用户体验的系统。

    此部分此结束,希望本篇文章能帮助到需要的小伙伴们~

    题图来自Unsplash,基于 CC0 协议。

    声明:本站部分文章及图片源自用户投稿,如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢!

    上一篇 2022年9月16日
    下一篇 2022年9月16日

    相关推荐