【Lilishop商城】No3-2.模块详细设计，运营用户模块的详细设计

仅涉及后端，全部目录看顶部专栏，代码、文档、接口路径在：

【Lilishop商城】记录一下B2B2C商城系统学习笔记~_清晨敲代码的博客-CSDN博客

---

 全篇会结合业务介绍重点设计逻辑，其中重点包括接口类、业务类，具体的结合源代码分析，读起来也不复杂~

谨慎：源代码中有一些注释是错误的，有的注释意思完全相反，有的注释对不上号，我在阅读过程中就顺手更新了，并且在我不会的地方添加了新的注释，所以在读源代码过程中一定要谨慎啊！

目录

A1.运营用户模块（仅M端操作）

B1.设计逻辑分析（熟悉后可略过）

C1.用户

C2.部门

C3.菜单

C4.角色

C5.登录/注销

个人补充：

B2.请求接口分析

C1.用户&登录/注销

C2.部门 

C3.菜单

C4.角色

C5.部门-角色

C6.角色-菜单 

B3.业务分析说明

C1.关联类

C2.认证鉴权

---

A1.运营用户模块（仅M端操作）

之前在系统搭建里面有描述过用户登录、认证鉴权的框架设计【Lilishop商城】No2-2.确定软件架构搭建一（本篇包括MVC框架、持久框架、缓存、认证工具、安全框架等）

其中有 framework 模块里的公共类，还有各个端自己的登录认证类，这里会再简单提一下，重点是在运营用户的业务。

shop系统里面的运营用户模块就是和大多系统一样，无非就是用户-菜单-部门-角色，用户的权限由角色确定，而角色来关联菜单（菜单即表示权限）。

接下就从三个方面来详细设计，先分析业务逻辑，然后将业务操作拆解为具体调用接口，然后可以再分析一下具体的业务类（业务类也可以放到编码阶段分析，我们现在的详细设计就只包括接口和设计逻辑，不包含业务类），同时要记得结合各个端来分析~

B1.设计逻辑分析（熟悉后可略过）

简单明眼一看就能看出来的逻辑，就不详细说了，比如用户新增、修改，但是用户涉及到的权限就属于隐式的内容，这个就需要说明一下。

C1.用户

主要是管理用户；用户会和角色、部门进行关联，用户只会关联一个部门，但是可以关联多个角色；添加用户时，并没有校验用户名和手机号码；其余的没什么好说的。  

C2.部门

主要是管理部门；部门采用级联，每个部门都会有上级部门id；部门会和角色进行关联；其余的没什么好说的。

C3.菜单

主要是管理菜单；路由名称需要唯一，用于前端；权限url集合后端使用；其余的没什么好说的。

C4.角色

主要是管理角色；角色会和菜单关联；其余的没什么好说的。

C5.登录/注销

这个逻辑之前说过，1.用户登录时，生成accesstoken并缓存60分钟，拿到权限列表并缓存无期限，最后返回accesstoke。2.用户携带accesstoken访问，先判断accesstoken是否存在，存在即有效，就从缓存中拿到权限列表并生成AuthenticationToken，之后鉴权；若不存在则直接抛异常返回。3.用户登出时，直接从缓存中删除accestoken；

个人补充：

1.shop系统中，编辑用户时，并没有更新缓存里面的权限，这样会导致更新用户权限，用户新的权限需要重新登录后才能够生效。如果用户登录的accestoken是可自动更新时效的，那么可能会导致新的用户权限一直无法生效哦（虽然现在accestoken是没有自动更新时效的）。

本来我是想着在编辑用户时清除缓存重新更新，后来一想，更新角色权限、更新部门角色时，都会影响到用户权限，总不能所有地方都清除吧，于是就看到系统里面的更新token接口，那不正好加这里面嘛，虽然不会实时更新，但是失效不会太长。然后一看代码就发现系统也是这样的~

2.添加/注册用户时，并没有校验用户名和手机号码，这个是一定要校验的

3.shop系统的权限这里不太合理的是，权限是仅有操作权限和查看权限，不会精确到按钮，并且前端也并没有针对权限做出按钮的显式/隐藏，也就是菜单鉴权前后端后有，而按钮的仅有后端鉴权，前端无论有没有权限都会显示！十分不推荐

B2.请求接口分析

正常情况下，接口的入参出参一定要在开发前写清楚的，例如可以使用ApiFox进行管理，这样前后端对接就会很协调~如有涉及到测试的，会写在 ApiFox 里面，我这里就不写详细出入参了，详细api公开链接见顶部~

C1.用户&登录/注销

• 用户的多条件分页获取用户列表、增加用户、编辑用户、删除用户、禁用/开启、重置密码；
• 当前用户的编辑、修改密码；
• 用户的登录、注销、更新token； 
• 部门的获取级联列表（见部门模块）；
• 角色的获取列表（见角色模块）；

入参除了基本数据外，还有AdminUserDTO、AdminUserVO，DTO用于接收入参，VO用于出参，不使用实体类是因为实体包含内容不满足使用，二是怕出参中包含敏感信息；

   

C2.部门 

• 部门的查看单个部门详情、获取级联列表、增加部门、编辑部门、删除部门；
• 部门-角色的查看部门拥有的角色列表、更新部门的角色（见部门-角色模块）；
• 角色的获取列表（见角色模块）；

 入参除了基本数据外，还有Department，也就是实体类

  

C3.菜单

• 菜单的获取级联列表、获取当前用户权限、获取搜索菜单列表、增加菜单、编辑菜单、删除菜单； 

 入参除了基本数据外，还有MenuVO

  

C4.角色

• 角色的获取角色分页列表、增加角色、编辑角色、删除角色； 
• 角色-菜单的查看某角色拥有到菜单、保存角色菜单；（见角色-菜单模块）

 入参除了基本数据外，还有Role，也就是实体类 

 

C5.部门-角色

• 部门-角色的查看部门拥有的角色列表、更新部门的角色；

 入参除了基本数据外，还有DepartmentRole，也就是实体类

C6.角色-菜单 

• 角色-菜单的查看某角色拥有到菜单、保存角色菜单；

 入参除了基本数据外，还有RoleMenu，也就是实体类  

B3.业务分析说明

是针对复杂的操作/请求接口添加的业务描述，例如：编辑部门接口中，还需要调用更新部门的角色接口，这种需要给出说明。并不是每个接口都会给出。

这里的业务类没有复杂的逻辑。

C1.关联类

角色-菜单，部门-角色，这两个关联类需要给出接口，并且要结合业务进行调用。

角色-用户关联类就不会用到请求接口了，因为直接在用户请求的业务中操作了。

C2.认证鉴权

用户登录后拿到accesstoken，然后获取当前用户权限（即菜单权限），然后前端根据这个展示菜单。然后用户点击按钮时会调用接口，后端会先判断用户的权限列表中权限URL是否能匹配此请求路径，不能匹配则直接返回权限不足。

【所以鉴权是通过PatternMatch匹配的，而且菜单表里面的权限url要和接口的请求url对应！！！私以为这样的逻辑其实不太好，可看看pig、若依的逻辑】