项目需求分析
要做到工业水平的分析是不太可能的,咱还没那个能力。那就来个乞丐版本的分析吧。
前端需求
千言万语不如几张图片啊。手动狗头!
简单来说,体验流程如下:
1、购买设计服务(傻瓜式设计的服务),微信服务通知/公众号通知用户订单信息及添加客服微信
2、后台通过企业微信群通知同事:“您有新的订单,请及时查收!” (你懂的)
3、添加客服微信,提供logo等基本信息(重点是要把客户转化至私域)
4、设计完成后上传至后台,微信服务通知/公众号通知用户进入小程序下载,要么干脆客服微信直接发给客户
5、或者转化至定制服务
6、服务结束
另外
消费会有积分,积分可通过积分商城来兑换公司出品的公共关系物品,如鼠标垫、笔、水杯等。
重点:
1、设计服务的商城
2、积分体系
3、会员中心
4、积分商城
5、订单关系
服务端需求
这个貌似有点大,思维导图都给整满了,貌似也没完全理清。
- 商品管理
1、设计服务和积分可以同一个数据模型,因为设计服务可以按产品分好几种,再加上积分商城的模型,那么有必要抽象一个基类出来。具体模型移步下一篇文章。
2、自动生成商品编码,而且是阅读相对友好且唯一的,这有利于对商品进行管理,数据表默认的id没办法对商品进行管理
3、图片上传至腾讯对象存储系统即COS,返回一个链接保存到服务器中(上传后自动生成缩略图,并和原图一起上传到COS,原图上传这个是没问题的,django后台操作时缩略图和原图一并上传并返回两个url,这个还没整明白怎么么搞)
4、商品要有折扣价、赠送积分
5、商品要有上下架、是否显示在首页功能
6、商品要保存一个相对路径,这个路径可以提供小程序前端从轮播图发起请求(我把每一种设计服务都设计成了一个独立的app,banner没办法通过外键来关联到所有的设计服务)
7、角色权限管理,细分到对字段的管理,这个简单,django的auth
和permisson
可以搞定
8、财务管理,销售额、订单量,还要考虑到退款的问题(理论上虚拟商品不支持退款)
9、数据看板,大概可分为总额、日、月、年等维度的统计
10、有业务流程变动时,企业微信群通知同事处理,这个估计也没多大问题,大概看了企业微信的文档,我能hold得住
11、微信支付。这个我估计够呛,暂时还没接触过
12、与公众号的对接,实现信息通知
好了,暂时想到这么多。