组织结构与权限模型设计(一)

前言

权限模型是企业管理软件最基本,也是最重要的功能之一,它属于系统的基础架构,涉及到对数据、操作功能的权限控制。它的难点在于如何将企业的日常管理合理地映射到系统的业务功能,使用户在使用系统的时候就跟日常办公一样自然,同时又能享受到办公自动化带来的效率提升。

在这次Qone Online的产品开发过程中,关于权限模型的方案讨论所花费的时间甚巨,演变出了很多种思路,本系列主要记录方案讨论的过程,一方面作为宝贵的经验财富,另一方面,也便于以后再回顾的时候看是否会有更加完美的方案。

 

分析

企业管理系统五花八门,这里我以软件企业的项目管理系统作为切入点进行分析。项目管理系统顾名思义主要是用于企业对项目进行管理,包括项目的立项、计划、跟踪、进度管理、成本管理、成员报工管理、绩效统计等业务功能。作为一个企业,会涉及到企业的部门组织结构以及人员职责的划分;而作为一个项目,它也可能处在一个复杂的项目组织结构中,典型的项目群组织是由项目组合、项目集、项目三类节点组成(关于三者的概念,可阅读我另一篇博文项目,项目集以及项目组合),所以项目也会涉及到项目组织结构以及人员职责划分的问题。

对于部门组织这个维度来说,涉及到的业务实体有哪些呢?联想现实的部门场景,首先我们能很容易识别出部门,其次部门里面肯定会有人员,人员一般会有职位,比如某某是部门经理,某某是财务助理;而对于项目组织这个维度来说,我们很容易识别出项目人员等实体。

接着我们需要把现实的场景与系统关联起来,在系统里面,人员我们一般叫用户,对用户来说他需要操作系统中的功能,用户能操作什么功能,我们叫做权限,具有什么样的权限就能操作什么样的功能。权限需要分配给用户,一般来说一组用户可能具备相同的权限,比如各个部门的部门经理操作权限都差不多,这时候为了方便,我们把一组权限打包赋给各个成员,而这个打包的权限就叫做角色。一个角色对应多个用户,而一个用户可以具备多个角色,两者之间是多对多的关系。

 

方案一

这样,我们就把权限和用户通过角色关联了起来,这就形成了典型的用户-权限-角色权限模型。如下图所示:

 

图一 用户-权限-角色关系图

 

 

其中,角色与权限,用户与角色,均是多对多的关系,即一个角色包括多个权限,而一个权限可以属于多个角色共有;用户与角色的关系与此类似。

而对于部门组织结构这个维度来说,前面提到,还涉及到部门和职位两个业务实体。一个部门包括多个用户,而一个用户可以同时属于多个部门(兼职的情况),故两者的关系是多对多。一个部门通常会包含多个职位,而每个部门的职位一般来说是不一样的,比如开发部和行政部的人员,职位肯定是不一样的,一个是软件工程师,另一个可能是行政助理,故两者之间的关系是一对多,即一个部门包含多个职位,而一个职位只属于一个部门;由于用户可以同时隶属于多个部门,故可能会同时兼任多个职位,而一个职位下面通常也会有多个用户,故两者之间是多对多的关系。由此,形成了如下的关系图,其中双向箭头代表多对多关系,单项箭头代表一对多关系:

 

图二 部门组织权限模型

以上只是从部门组织维度描述权限模型,在项目组织的维度,同样也需要关联用户、权限和角色。三者的关联与图一所示的完全一致,但是这里需要考虑一个问题:比如有一个叫做项目经理的角色,他具备一系列操作权限,把这个角色分别赋给了张三和李四,张三在项目一,李四在项目二,那么张三是否能去操作李四的项目二呢?当然不能!这里就涉及到一个领域的概念,项目经理这个角色只有在与具体项目绑定了以后才有意义,并且绑定后,项目经理就只能操作本项目的数据,而不能去操作其它项目的数据。这个绑定的项目就是项目经理所能操作的领域。部门经理与此类似,虽然各个部门的部门经理操作功能差不多,但是能操作的数据范围仅限于本部门。

为了清晰,我们对角色进行了分类,分成了三类:项目级角色、部门级角色、系统级角色,它们针对的领域分别是项目、部门、系统。

 

总结

在本方案中,职位只是作为组织结构中人员的一个标签,在系统中没有特殊的含义,也不与操作权限相关,只有角色才与操作权限相关。用户通过赋予其角色,间接赋予了其操作系统中相应功能的权限。

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
【实例简介】 项目采用经典DDD架构(用沃恩.弗农大神的话,其实这是DDD-Lite)思想进行开发,简洁而不简单,实用至上,并且所写每一行代码都经过深思熟虑,符合SOLID规则! ####当前版本 3.0 alpha版(2017-2-7) 采用全新工作流,实现自定义表单处理; 2.0版(2016-10-31) 支持多流程模板; 增加Ace admin界面支持 秀外 输入图片说明 输入图片说明 输入图片说明 慧中 教科书级的分层思想,哪怕苛刻的你阅读的是大神级精典大作(如:《企业应用架构模式》《重构与模式》《ASP.NET设计模式》等),你也可以参考本项目。不信?有图为证,Resharper自动生成的项目引用关系,毫无PS痕迹! 输入图片说明 实用 符合国情的RBAC(基于角色的访问控制),可以直接应用到你的系统。 权限资源 菜单权限 经理和业务员登陆系统拥有的功能菜单是不一样的 按钮权限 经理能够审批,而业务员不可以 数据权限 A业务员看不到B业务员的单据 字段权限 某些人查询客户信息时看不到客户的手机号或其它字段 用户应用系统的具体操作者,我这里设计用户是可以直接给用户分配菜单/按钮,也可以通过角色分配权限。 角色为了对许多拥有相似权限的用户进行分类管理,定义了角色的概念,以上所有的权限资源都可以分配给角色,角色和用户N:N的关系。 机构树形的公司部门结构,国内公司用的比较多,它实际上就是一个用户组,机构和用户设计成N:N的关系,也就是说有时候一个用户可以从属于两个部门,这种情况在我们客户需求中的确都出现过。 ####系统工程结构: OpenAuth.Domain 系统领域层 OpenAuth.Repository 系统仓储层,用于数据库操作 OpenAuth.App 应用层,为界面提供接口 OpenAuth.Mvc 采用基于jquery与bootstrap的B-JUI界面 OpenAuth.UnitTest 单元测试 Infrastructure 通用工具集合 ####使用 管理员可直接在登录界面点击基于精典DDD的权限管理 - 点击以开发者账号登录登录; 普通应用账号使用:test(密码:test)登录; ####后续 更多狂野的功能,正在玩命加载中,敬请期待... 更多文档正在整理中.... 当然,如果你想学习完整的DDD框架,可以参考我的另一个项目(BestQ&A--开源中国推荐项目/集CQRS AES等DDD高级特性于一体的问答系统) 【实例截图】

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值