发表于： 2019-06-03 20:35:36
1 674
今天完成的事情：
任务6的总结和深度思考；
1.后台：实现前台的内容修改、编辑、查看等功能的系统，对信息进行创建、存储、处理的地方，也叫管理系统。
企业管理系统，是指能够体现企业管理的大部分职能（包括决策、计划、组织、领导、监控、分析等等），能够提供实时、相关、准确、完整的数据，为管理者提供决策依据的一种软件。以模块划分，企业管理软件可分为财务管理、车间管理、进销存管理（ERP）、资产管理、成本管理、设备管理、质量管理、分销资源计划管理、人力资源管理（HR）、供应链管理（SCM）、客户关系管理（CRM）等品种。
我给后台分成两种，一种是to c 产品（前端产品）的后台，还有一种是b端产品（后端产品），也就是企业管理系统；
前者的使用者多为C端产品的运营、产品经理等，后者的使用者多为企业员工，比如人力资源管理的使用者就是企业的HR；
所以根据产品前后端的不同，产品经理也分前后端：
前端产品经理的关键词在于：用户、场景、体验、转化、价值挖掘。在根据用户和市场挖掘需求。
后端产品经理的关键词在于：业务、逻辑、跨越、结构、控制、数据。在根据业务和发展规划需求。
2.后台管理主要分为四个部分，模块管理、角色管理、密码修改、账户管理
2.1模块管理：模块是单独的一个功能，平台由多个模块集成，可以使用多个功能。模块管理即对多个模块进行管理。
2.1.1模块管理功能：a.对各个模块增删改 分类排序 b.对各个功能模块启用停用
2.1.2模块列表名词：
a.id：数据库分给后台每个模块的唯一编码
b.名称：后台对每个模块的命名
c.URL：域名，IP，资源类型-存放资源的主机域名-资源文件名
d.父节点：功能或模块的上一级，朋友圈的点赞功能，点赞功能朋友圈功能的子节点，朋友圈是点赞功能的父节点
e.icon：装饰后台管理模块
f.排序：对模块列表进行排序
2.2账户管理：对后台账户体系中的所有账户进行增删改，包括用户名、密码和角色。只有权限高的账户才会有账户管理功能
2.2.1账户管理分类：对内账户（对内部人员设立的账户，给部分权限，可以对前台后台进行权限内操作），对外账户（用户管理，在前台注册的用户，自动形成用户列表，可以对用户列表进行操作）
2.2.2 账户管理和用户管理的区别：账户包括对内的和对外的，用户只是对外的，即前台自行注册的账号，对内的是管理员生成的
2.3角色管理：用户——角色——权限，用户身上多个角色，角色身上有不同的权限，对用户进行角色的赋予、修改、收回。
2.3.1角色：
a.角色是对后台权限的分组
b.每个权限都是单独存在，角色是不同特定权限的组合
c.角色是权限的载体
d.将所有权限分类，不同角色授予不同权限
2.3.2权限设计
a.用户-角色-权限，给角色设置权限，然后用户更替
b.用户-职位-角色-权限，一个用户下可以设置多个职位，一个职位只能对应一个角色。
2.4密码修改：权限高的账户能修改所有账户的密码，包括自己；权限低的只能修改自己的
3.后台的作用以及后台怎么设计才好？
实现前台的内容修改、编辑、查看等功能的系统，对信息进行创建、存储、处理的地方；
这里我们只考虑C端产品的后台，不考虑后端产品，如果想找后端产品的工作，比如ERP，可以深入了解学习；
后台设计的基础原则：可视化原则、数据源原则、控制性原则、内部设置原则
可视化原则：对后台数据统计内容进行查看（允许各种维度的查看，不允许操作），遵循可视化原则常见的功能，包括我们的多维度筛选、排序、到处、数据明细、饼状图、折线图等，都符合可视化设计原则，用最合适的方法，提高我们查看信息的效率
数据源原则：典型特征在于新增，不具备新增功能的后台是不符合数据源原则的，这表示该产品几乎不具备可运营能力，运营也无法通过后台对产品的内容、风险、活跃度进行干预。数据源原则便是要求我们后台要具备”生产新内容“的能力。
控制性原则：后台操作人员能够对用户的部分信息进行修改，属于保护机制，在用户发出不好的内容可以有所作为。在保护内容生态的同时，当用户执行了某些不可逆操作时，我们也需要保护。
内部设置原则：最常见的内部设置是我们的权限系统，与面向用户的产品毫无关系。这部分功能的设计对象仅仅是明确操作者的权限范围。内部设置原则更多的是服务于后台产品本身的功能，他和用户，和我们面向用户的产品没有任何关系。
总结：可视化原则的设计对象是我们看不见的信息，数据源原则的设计对象是新建内容，控制性原则的设计对象是用户及用户生产的内容，内部设置原则的涉及对象更多的是后台本身的功能。
简单来说，就是第一我要可以查看到前端存储的数据，通过筛选等方式提高查看效率，第二运营可以新增内容，第三管理员可以修改用户的部分信息，第四就是可以管理后台的账户和权限；所以后台最基本的就是后台管理模块和内容管理模块两部分。
4.后台设计中的Content（Article）表是为了解决什么问题，在前台什么样的功能可以用Content处理？
Content就是内容管理，主要的作用前台内容格式一样，定制化需求低的时候，如：公告，banner，侧边栏通知，联系我们，常见问题等功能，其实这些功能只不过是前台渲染方式不同，后台编辑时完全可以定义成通用的标题、摘要、内容、缩略图、跳转链接等，可以提高复用性和降低开发成本，也满足产品运营的需求；
例如：banner，后台可以自定义一些通用字段，对每条详情可以进行上下架、编辑、删除等操作，也可以新增；
5.后台里的角色，用户，模块之间的关系是什么，如果加入部门，岗位又该怎么设计？如果支持用户有多个角色，怎么处理？
角色是权限的集合，所以在后台里，角色决定了用户可以对后台中的哪些模块进行哪些操作；
加入部门，可以在RBAC的模型基础上进行扩展，加入用户组的概念，给账户分配角色，再把账户加入到用户组，也就是部门中，这样用户除了本身拥有的角色权限以外，还拥有所属用户组的所有权限，用户组的概念可以更方便的给群体账户授权，且不影响到账户本身拥有的角色权限；岗位存在于部门下，你在哪个岗位就拥有哪个岗位对应的角色，所以岗位和角色是一对一的关系；
想要用户有多个角色，前提是这些角色是不是互斥的，比如一份文件的审批流程中，你不能既是提交者又是审批者；
6.权限的维度一般是怎么样的，如果是限定在对某一个模块的细粒度操作控制怎么办？比如说限制只能读，不能编辑，应该怎么设计？
权限分为页面权限、操作权限、数据权限；
一般的较为简单的设计会将权限关联到摸个模块或者页面，角色获取相关权限的页面访问权，如有设计需求可以将模块、页面的按钮权限关联给角色；基本上是以单元拆份，以业务逻辑配置；
可以将每个对象的增删改查各作为一个基本的权限单元，从设计上达到低耦合以及模块化；但是在实际业务中可能 有些操作是一体的，不便于拆开分权限，可以让前端进行渲染时打包成一个整体进行提供配置，比如增删改打包成操作权限；
此外，角色与权限之间的关系并不仅限于角色是否有这个权限，还应该包括对该权限的数据访问程度；比如数据范围，用户拥有查看人员列表的权限，但只能查看自己部门的；拥有数据边界线制：一个高级管理员最多能增添5个初级管理员；拥有数据字段限制，普通员工只能看到报表中零件的数量，经理可以看到报表中零件的数量和单价；
7.为什么要设立角色，账户是否可以允许有多个角色？权限为什么不直接分配给账户？
角色是对后台权限的分组 ;每个权限都是单独存在，角色是不同特定权限的组合 ;角色是权限的载体 ;将所有权限分类，不同角色授予不同权限.
一个账户可以有多个角色，一个角色可以有多个账户。
权限如果直接分配给账户，在账户更替或者权限分配收回的时候就十分麻烦，过程繁琐，工作量巨大。
明天计划的事情：
1、任务6应该没啥问题了，开始任务7；
2、后面找时间把之前的任务也梳理总结一下；
遇到的问题：
1、今天上午看了几位师兄任务6的日报，发现自己任务6学的深度和知识点的掌握还是不够。此外发现自己虽然做到任务6，但是对以往做的任务缺少深度的思考和总结，没有复盘，所以今天将任务6中所有的知识点重新梳理了一遍，包括任务6后面的深度思考，形成总结；
收获：
1、对后台管理系统和权限有了更深的理解；
返回列表
评论