第一章 前言

        相比前端设计，我更喜欢设计后台管理系统。如果说前端设计考验的是共情能力，那后台管理系统设计考研的就是逻辑能力，前者需要站在用户的角度，后者是站在管理者的角度思考。

        有幸参与了公司不少业务系统从“0-1”的设计，比如客户信息中台系统、小型电商小程序、固定资产管理系统等，这些系统从前端到后台无疑都是自己独立设计的，虽说成就感很满，却有点气馁，身边的好友、同事看过前端的功能模块后都会一副“就这？”的表情，毕竟为公司业务服务的产品，也只能按照公司的发展战略设计，这么一来前端UI平平无奇的前提下，功能点也显得平平无奇，仿佛只有产品和研发才知道精髓在于后台设计。

        前面几篇也有提过我是从技术转行过来的，因此对于后台管理系统的设计有自己的方法和见解，仅此记录，如有谬误，多多指教。

第二章 项目概述

2.1 项目背景

        公司业务有销售软件、销售硬件、销售服务等，不同业务部门负责销售不同的产品，其中有一项是由业务部门A推出的培训课程（有免费也存在付费）销售业务，现在各大企业大力推广信息化、无纸化办公，公司也不例外，想要有个小程序协助各个业务部门销售公司产品，包含培训课程。

2.2 项目需求

1. 需要一个小程序销售公司产品；
2. 业务部门可以通过后台上架付费/免费课程；

【作者有话要说：实际业务要比这个复杂，比如有管理订单、派发优惠券、管理学员上课情况等等，角色也不止这几种，这里拿其中一个商品管理流程做案例】

第三章 方案设计

        “面向对象”是一门很有意思的学问，所以我拿到需求后，先从对象出发，进行简要分析，需求中有什么角色，每个角色要做什么事情，从而确定主体及主体间的关系，主体可以协助我们分析表字段，主体间关系协助我们确立表之间的关系，从而确定功能模块，根据功能模块输出原型图。

3.1 需求分析

结合项目背景及需求，可以得出以下结论：

1. 该公司有很多业务部门；
2. 各业务部门上架属于自己部门的产品；
3. 产品中包含课程、硬件、软件、服务等；
4. 课程有付费也有免费；

3.2 分析主体

分析主体时，建议用ER图，即实体关系图，ER图可以清晰看出主体的字段以及主体间一对一或一对多的关系，前面也提到了，主体间关系可以协助我们确定功能模块。

从需求分析中，可以看出，主体有公司、业务部门、商品、课程...

1. 公司里包含多个业务部门
2. 业务部门包含多种商品
3. 于业务部门A来说，商品即课程

因此，公司和业务部门是1:n关系，业务部门和商品是1:n关系，商品和课程是1:1关系

 3.3 产品结构 

        后台管理系统离不开主体的管理，有了ER图后，便可以利用思维导图梳理产品结构

        程序员中有个术语，叫“解耦”，即降低模块间的关联关系，所以每个主体都作为一个独立管理模块，方便以后方便业务拓展、运维

        根据ER图的关联关系，被包含的主体管理模块字段中，要有包含它的主体id

        如：商品包含了课程，那课程管理表中，需要有商品id，完美建立关联关系        

        可能有的小伙伴很疑惑，既然商品和课程是1:1关系，那为什么不直接在商品管理处管理课程

        前面提到，课程是有免费也有付费的，而价格是商品的属性，课程关联商品就需要付费，不关联即免费，除此之外，商品不止是课程，还可能是硬件、软件，独立管理商品和课程能实现最大程度上解耦。

3.4 原型设计

3.4.1 公司管理

3.4.2 业务部门管理

3.4.3 商品管理

 3.4.4 课程管理

第四章 总结 

         这个流程虽然只是个小业务，但也利用了面向对象思维和ER图解决问题。末尾了，想说话也没那么多，那就祝大家平安喜乐。