问题一：对于APP后台的设计，APP后台独立设计还是与网站后台设计在一起比较好？

答主对这个问题还想追问一句：你提及的app和网站承载着同样的功能和内容吗？

1. app和网站承载着不一样的功能和内容（例如：滴滴的网站和app）

这种情况，一般网站是公司以市场推广为目的来运营的，往往会展示公司文化、媒体报道、项目简介、甚至产品demo等，让用户有一个官方渠道来了解公司所做的事情，并且还有引导用户下载app的作用，而app是公司真正的产品，承载着业务功能。也就是说，网站由市场推广方向的人通过后台系统维护，而app则是产品运营通过后台系统维护。根据网站所管理的内容是否多且复杂来决定是否要跟app的后台分开设计，如果多（有的公司网站要放招商入口、还要轮播媒体报道、投放人才招聘等等），建议分开设计，网站后台针对市场推广的需求设计，app针对业务来设计；如果少（有的公司网站就放个万年不变的介绍，加上一个随时要换的下载app），就放一起，在后台建立子系统或者功能子模块即可。

2. app和网站承载同样的功能和内容（例如：京东的网站和app。随着移动互联网的崛起，许多公司以网站发家，有着从网站向移动端导流的需求，又或者因为网站和app技术层面的局限性，会出现网站和app有不同功能的情况，这个暂不纳入这次讨论范围）

这种情况的话，app和网站所承载的内容往往会由同一个后台管理（注意啦：是内容由同一个后台管理，例如：商品库，体量大的公司会根据业务流所设计的实体拆分成若干个后台系统，例如：电商网站会拆成订单系统、商品库等等）。

问题二：在设计后台时，有哪些需要特别注意的地方？

后台系统的主要功能就是维护业务流中的实体（小妙招：如何鉴别实体？在设计系统时，会收集需求、描述场景，这里面出现的名词，这些名词就是实体。例如：张三在某电商平台上用优惠券买了台笔记本，这里面实体有张三、优惠券、笔记本，分别代表买家、优惠券、商品，那么后台就需要对买家信息、优惠券信息和商品信息进行管理），以及维护实体和实体之间的关系（例如：买家会购买多见商品，商品会被多个买家购买，多对多的情况下，就需要有一个实体来维护这份关系：订单）。还有些功能是为了给研发人员偷懒用的，例如：app广告位的图片替换。

回顾答主的过往经验，觉得在设计后台时需要注意以下几点（血泪史）：

（1）记得做权限分离和操作日志：权限的粒度越细、操作日志越详细，越容易定位问题以及控制风险，例如：造成某个商品下架有很多原因，运营下架、售罄下架、优惠活动截止下架，当运营发现这款商品近今日销量为0时，一查发现只知道最终状态是下架，看不出是什么原因，就会很崩溃；

（2）充分理解需求，明确实体和实体之间的关系：是一对多？还是多对多？还是一对一？如果一开始不理清楚，那后面就要花好多精力埋坑，例如：做组合商品优惠时，一个组合包含多个商品，那要支持一个商品可以参与多个组合吗？支持的话是一套设计逻辑，不支持的话又是一套设计逻辑（例子有些偏颇，大家懂我意思就好）。

最近忙的连复盘的时间也没有...所以自己都觉得答的太匆忙，有什么想起来的，以后再来补充～