在搭建一个管理后台的时候首先要对这个系统有一个初步的规划，就是这个系统将来会覆盖那些行为，那些是不在设计之中的，这样既可以为系统定一个基调也可以将来在跟产品汪砍需求的时候直接摊牌“对不起，系统设计之初没考虑覆盖这个方面的功能”(当然能不能砍的掉看你能力)。
做后台最初的需求一般都比较简单，如管理一下内容的增删（内容管理)改这种的。但是对于公司来说这些东西都是不能给外人访问的，所以身份认证是一个在处理其他功能之前必不可少的模块，当然身份认证这种功能处理可大可小，我曾经见过用户名密码是写在代码中的（😅）。
当系统功能少时一切都可以从简，但是后台一般都承载了一个前台网站相关的所有其他功能，稍稍有几样业务，后台功能就会开始膨胀，这个时候处理不同业务的人的权限也是不一样的，这个时候就要开始区分权限(权限系统)了。后台的功能权限刚开始都跟公司业务职别相关，如果这个时候对于系统已经有了但只是上述简简单单的样子，那么这时候只需要稍稍改动，在用户的基础上添加个角色的属性，一切又可以流畅的用起来了。
如果系统完成了以上功能，那么这个系统基本的处理功能已经差不多了，但是这只是对于处理层面而已，对于系统而言，你看到的数据都是事时的，稍微有点后顾之忧的老板都会有顾忌，万一那个员工从中捣鬼删了系统中的数据怎么办？这个时候就需要有日志系统了，在系统中记录用户的操作行为，可能如果有必要连当时操作的数据都备份下来。这是其一，当一个业务需要有多用户参与、或多个步骤才能完成时这个时候可能就需要流程处理相关的设计了，因为刚开始还好，业务方一拍板把流程定了下来，开发完成过了半个月业务方觉得这么这么滴不是很合理可能要调整，如果当初代码啊结构啊设计的好还 OK 如果整个颠覆了，那你就等着吧。作为一个开发很多时候都有这么个抱怨“能不能把需求理清了再来找我啊，天天改来改去的！！！”，但是切换一下角色来看一个业务模式尚未清晰之前一切调整都是可能的，就算业务清晰了，需求可能还是要调整的。所以作为一个开发就是尽早发现需求之间的共性，然后抽象成一套完整的模型（当然这个过程中间还是要和产品不断进行沟通的），这样不仅能尽快处理业务方的调整，也能让自己少写代码早下班。
后台里有了流程系统说明公司的人员和业务都在逐渐明朗，这是个好事情，当然紧跟着的需求就是 KPI。程序猿的职责是什么，程序猿的职责就是一切能用编程搞定的事情就尽量不要浪费人力去处理。所以开发报表功能势在必行，开发吧！
还是关于流程，这里先引用一下百科定义：由两个及以上的业务步骤，完成一个完整的业务行为的过程，可称之为流程；注意是两个及以上的业务步骤。既然是两个以上的业务步骤，那就可能由多人协作完成，或者是分时段完成，但不大可能是一个人在同一时间完成这一系列步骤。如果要协作必然要沟通，沟通可以通过 qq，微信，email 等等沟通工具，但是人么多多少少都会忘记连发个通知都可能会忘记。所以这个时候产品经理说”来个消息提醒“，于是系统里就有了消息提醒，一般情况下有了消息提醒该忘的还是会忘记，但那跟我什么关系！
OK，以上讲的是一个管理系统大致的产品发展趋势。现在开始总结对于开发人员都有哪些模块要设计，我写在下边并按照重要程度进行了排序
1. 数据管理
泛指增删改查，对于查询又有筛选、搜索、排序、分页等一系列问题，更复杂的可能还会有分词的要求。对于增改则有前后端数据校验的问题要处理。对于删除看起来简单，其实有数据完整性和系统功能完整性的校验。
2. 认证系统
主要处理验证用户身份，实现方案有很多。相应问题也有很多，比如弱口令、明文存储密码、撞库、穷举暴力破解、SQL 注入等等一系列需要注意的问题。
3. 权限系统
权限管理初衷莫过于：不同的人拥有不同的功能。简单方案和复杂方案实现起来也天壤之别。
spa github 地址：https://github.com/chen-wen/vue-spa
4. 日志系统
对于诗人“天空不留下飞鸟的痕迹,但它已飞过”，对于程序猿“飞过飞不过都得留下痕迹”
5. 流程管理
定义：由两个及以上的业务步骤，完成一个完整的业务行为的过程，可称之为流程；注意是两个及以上的业务步骤
如果你处理过流程相关的业务你自然之道其中的难易
6. 报表系统
依赖流程，指导流程
对于运营大多是以结果为导向的，而数据就是业务方的 KPI 和修改流程的依据。
7. 消息系统
暂无
