最近参与一个项目的架构设计，及提供技术指导，发现其用户体系相当复杂，之前自己的设计显然想简单了。其大概的要点如下：
1. 这个系统的用户包括一千多所学校的学生、家长、校长、校医、主管部门的工作人员、领导、第三方机构工作人员等；
2. 一个学生可以被多个家长绑定，一个家长也可以绑定多个学生；
3. 一个账号可能有多种角色，例如既可以是家长，也可能是校医校长、工作人员等；一个学生长大之后，也可能成为校医校长等；
4. 可以使用账号密码登录，还可以使用手机号登录，也可以使用绑定微信登录。
周五大家开完会，关于这个用户与权限体系感觉还是有点混乱，故写下这个文章进行梳理。
前面也写过两篇权限系统的文章：文章1，文章2。
图片来自文章
之前的设计及实施的偏差
之前的设计其实是一个比较通用的方案，设计要点：
- 所有用户的公共基础信息都在一个用户表里，由一个uid进行标识，不同用户类型的信息存储到扩展表上；
- 由统一的部门树来组织用户，无论是地区、学校、年级、班级，还是主管单位的各级部门或者第三方机构等，都是部门树的节点，所有用户都关联到一个或者多个部门树的节点上，这样就有可能可以实现统一的数据权限；
- 统一的角色管理，无论是家长学生，还是校医校长，都是角色，这些角色可以查看哪些页面，可以操作哪些功能，对哪些部门的数据有权限等，都是通过角色进行控制；
- 户、部门和角色三者关联起来，一套完善的用户管理与权限体系就完成了；
- 所有页面，无论是PC端，还是小程序端，还是子系统，所有页面及操作都应该是被权限体系覆盖的，哪个角色可以查看哪些页面都是通过权限项进行配置的。
这样的设计应该说是没有大问题的，也是可行的，也有足够的扩展性，不过在实施的过程中，却出现了偏差：
首先，开发对整体权限体系设计理解不够，虽然当初开了几次会进行对齐，不过显然当时还是不够透彻。主要体现在对权限项的理解上，每个页面及其功能的权限应该都是可配置的（低代码平台的思路也是这样），但是在开发的时候显然没怎么没有充分考虑到这一点（经验不足），这可能会导致权限都需要硬编码的情况，灵活性就降低了。
其次，部门树没有执行完整，年级和班级已经从部门树独立出去了，这样就绕过了原来的权限控制，如果说要对年级或者班级设置权限，那就得再实现一套权限判断，这是工作量，不过只是目前这个系统还不怎么需要考虑年级班级的问题，所以这个问题暂时还不会呈现出来。
因为已经开发了相当部分功能，这两个问题很难再纠正过了，只能做一些弥补。
低估的复杂性
之前设计的时候，有些问题考虑是不够的：
- 开始时漏考虑了一个角色：普通微信用户。这个系统可以开放给普通微信用户，通过微信进行快速登录，登录的时候就已经注册账号了，这时用户已经使用系统的一些功能了。复杂性在于后续该用户可以和学生进行绑定，这时他的角色就可能会转换成学生或者家长等，可能需要对账号进行合并，因为原来学生的账号本来就是预先生成在系统中的，如果是家长则需要对账号类似进行转换。
- 一个人可能既是家长，也是校医校长或者工作人员，怎么处理？这个问题一开始其实是有考虑的，但是没有细化，没有形成明确的认知，在设计用户基础数据表的时候，将部门和角色直接绑定到了基础表，这样就没法实现一个用户在不同部门有不同角色。在周五开会讨论的时候，大家角色再改这个工作量可能比较大，于是给了一个用户可以使用不同账号进行进行区分的方案，直接从账号层面进行隔离，应该说这是一种妥协的实现。
但是，关于第2个问题的解决方案是否有问题？
如果是全新的系统自然是没问题的，但是这是一个旧系统上的升级改造，有旧的数据，如果原来的旧系统本来就有类似的实现，那做数据迁移的时候，就会出问题，账号体系很难直接迁移过来，这个可能还得让需求人员把这个问题调研清楚。
问题产生的原因与教训
- 开发与架构设计沟通不够：这个可能是主要原因，架构在前面很难把所有细节都考虑到，特别是系统比较复杂的时候，这时舒畅的沟通机制就很重要，特别是跨团队的时候，有周例会对齐认知很重要；
- 开发前对需求的共识会应该更加充分些：理论上是这样子，有改进的空间，不过这可能会很消耗时间，在实际项目中可能很难执行到位，在没进入开发环节的时候可能很多细节问题也不会暴露出来，所以关键还是建立有效的沟通机制；
- 周例会的参与人员应该包括开发与测试人员，而不应该只有开发负责人和产品负责人，跨团队开发可能特别容易出现这种情况，要是跨多个团队那就更容易出问题了，很容易造成问题的累积。
