python-django电商项目需求分析
1.用户模块
1）注册页
- 注册时校验用户名是否已被注册。
- 完成用户信息的注册。
- 给用户的注册邮箱发送邮件，用户点击邮件中的激活链接完成用户账户的激活。
2）登录页
- 实现用户的登录功能。
3）用户中心
- 用户中心信息页：显示登录用户的信息，包括用户名、电话和地址，同时页面下方显示出用户最近浏览的商品信息。
- 用户中心地址页：显示登录用户的默认收件地址，页面下方的表单可以新增用户的收货地址。
- 用户中心订单页：显示登录用户的订单信息。
4）其他
- 如果用户已经登录，页面顶部显示登录用户的信息。
所以这个模块有5个页面
- 注册页
- 登录页
- 用户中心-信息页
- 用户中心-地址页
- 用户中心-订单页
2.商品相关
1）首页
- 动态指定首页轮播商品信息。
- 动态指定首页活动信息。
- 动态获取商品的种类信息并显示。
- 动态指定首页显示的每个种类的商品(包括图片商品和文字商品)。
- 点击某一个商品时跳转到商品的详情页面。
2）商品详情页
- 显示出某个商品的详情信息。
- 页面的左下方显示出该种类商品的2个新品信息。
3）商品列表页
- 显示出某一个种类商品的列表数据，分页显示并支持按照默认、价格、和人气进行排序。
- 页面的左下方显示出该种类商品的2个新品信息。
4）其他
- 通过页面搜索框搜索商品信息。
所以这个模块有四个页面：
- 首页
- 商品详情页
- 商品列表页
- 搜索结果页
3.购物车相关
- 列表页和详情页将商品添加到购物车。
- 用户登录后，首页，详情页，列表页显示登录用户购物车中商品的数目。
- 购物车页面：对用户购物车中商品的操作。如选择某件商品，增加或减少购物车中商品的数目。
所以这个模块就只有一个页面：
- 购物车页面
4.订单相关
- 提交订单页面：显示用户准备购买的商品信息。
- 点击提交订单完成订单的创建。
- 用户中心订单页显示用户的订单信息。
- 点击支付完成订单的支付。
所以这个模块就只有一个页面：
- 订单页面
####################################################################
架构设计的注意点：
注意1：前后端问题
上面都是讲的前段的内容，但是除此之外还有后台管理的页面，添加商品，管理我网站上面要显示的内容，
实际的公司里面开发项目，django有后台管理的模块，可以管理页面，但是像电商大型的项目，不会使用这个django后台，会专门开发后台管理页面，
那django的后台什么时候用？有一个项目你想要很快的做出来，就可以使用这个django后台先搭起来，
或者一个博客，或者做一个新闻类型的网站，你可以使用它的后台管理页面，
这个项目就是使用的django的后台管理功能，
注意2：数据库使用问题
实际开发中都会使用mysql数据库，这是使用最多的，
但是如果用户量非常大，会把常用的数据，或者是页面放到缓存里面，为什么？比如首页，首页的商品信息是数据库来的，但是展示的商品很长时间才动，
如果访问人非常多，比如1万人就要从数据库查1万次，就太频繁了，所以会把页面放到缓存里面，放到缓存的服务器里面，
而且用户来了之后需要存用户的session信息，如果用户非常大，你要不停的查数据库，所以还需要一个session的服务器，提高它的效率，
使用到的缓存数据库就是Redis数据库，内存型的数据库，这就是最常用的场景，使用Redis数据库，作为我们的缓存服务器，和session服务器，
注意3：异步任务处理问题
除此之外还需要异步的任务处理，比如注册之后，发送给用户一个邮件，这种比较耗时，就需要一个异步的任务处理，使用celery来异步处理这种耗时的任务，
注册之后，交给celery发邮件，不应该用户操作页面，该干什么干什么，就体验很好，
注意4：分布式文件存储问题
除此之外还涉及到商品的图片，对于一个大型的网站，涉及到很多的商品图片，django本身上传图片，它的效率是很低的，
在我们的这个项目中，就不再使用django默认的这个图片上传的处理，我们使用一个分布式文件储存系统，帮助我们存储图片，
这个系统叫fastdfs，这个分布式文件存储系统是一个淘宝的使用的一个系统，后来开源了，后来很多的电商网站就使用这个系统，
######################################################################################
数据库设计
这是非常重要的一环
用户表：ID，用户名，密码，邮箱，激活标识（表示用户是否被激活），权限标识（因为你要把管理员和普通用户放在一张表）
地址表：ID，收件人，收件地址，邮编，联系方式，是否默认（默认收货地址），用户ID（和用户是1对多的）
商品SKU表：ID，名称，简介，价格，单位，库存，销量（不放这也可以计算出来，但是按照人气排序，就是使用销量，可以减少关联的操作，就不用统计了，）
商品详情，图片（还是要记录一张，否则每次都要连表查效率低，这就是以空间换时间），状态（上下架），SPUID，种类ID，
商品SPU表：ID，名称，详情，
商品种类表：ID，种类名称，logo（这是种类前面的小logo），图片（这是种类的展示图片）
商品图片表：ID，图片，SKUID（和商品一对多，一个商品有多个图片）
首页轮播商品表：ID，SKUID（你是轮播的哪一个商品），图片（这是一个大banner），index（可以控制展示的顺序）
首页促销活动表：ID，活动图片，活动的url地址（跳转的可能不是一个商品，而是一个活动地址），index（可以控制展示的顺序）
首页分类商品展示表：ID，SKUID（我要展示哪一个商品），种类ID，index（可以控制展示的顺序），展示标识（比如1是展示成图片，0是展示成标题）
购物车功能：Redis实现购物车功能，并不打算建一个表，因为每次点击加商品和减商品，都要操作数据库，验证库存，这样可以使用Redis缓存，
但是我有疑问，为什么每次都要去校验呢？体验好，不然就是你要在提交的时候才知道库存不足，
至于怎么使用Redis放数据，实现购物车的功能，后续再说，
订单信息表：ID，订单ID，收获地址ID，用户ID（谁下的单），支付方式，商品的总数目（根据运营需求来，加上可以利于分析数据，不加也可以），
总金额（可以不加，但是加上有利于分析数据），运费，支付状态，订单创建时间，
订单商品表：ID，订单ID，SKUID，商品数量，商品价格（因为价格会变动，所以一定要记录），订单和商品是一对多，一个订单可以多个商品，评论
用户浏览历史记录：还是保存在Redis数据库中，
所以设计表的时候有一个套路，就是一旦发现有一对多的关系，就要分成两个表，
表在设计之前是需要仔细斟酌的，不可能今天该，明天该，不会频繁变动，
-------------------------------------------
电商里面SKU与SPU概念
SPU = Standard Product Unit (标准产品单位)
SPU 是商品信息聚合的最小单位，是一组可复用、易检索的标准化信息的集合，该集合描述 了一个产品的特性。通俗点讲，属性值、特性相同的商品就可以称为一个 SPU。
例如:iphone7 就是一个 SPU，与商家，与颜色、款式、套餐都无关。
SKU=stock keeping unit(库存量单位)
SKU 即库存进出计量的单位， 可以是以件、盒、托盘等为单位。
SKU 是物理上不可分割的最小存货单元。在使用时要根据不同业态，不同管理模式来处理。 在服装、鞋类商品中使用最多最普遍。
例如:纺织品中一个 SKU 通常表示:规格、颜色、款式。
举例：iPhone7是一个SPU，但是白色iPhone7是一个sku，黑色iPhone7也是一个sku，