从0开发前后端分离的企业级上线项目-电商平台二

今天我们讲讲项目开始我们需要做什么。

电商平台需求分析：这一般是产品经理需要做的。

一个电商平台有多大，淘宝几十年来就是做的电商平台。每一个宏大的项目都不是一蹴而就的。

需求拆分原则

单个迭代不宜太大

需求可交付，能够形成功能闭环

有成本意识，遵循二八原则

有预期的价值体现

电商功能拆分一一用户端

商品-> 首页、商品列表、商品详情

购物车-> 购物车数量、添加删除商品、购物车提交

订单-> 订单确认(地址管理)、订单提交、订单列表、订单详情

支付-> 支付

用户-> 登录、注册、个人信息、找回密码、修改密码

电商功能拆分一一管理后台

商品管理-> 添加/编辑商品，查看商品，下架

品类管理-> 添加品类，查看品类

订单详情、发货

订单管理-> 订单列表

权限-> 管理员登录

参与感

更深入了解业务和需求

丰富其他领域的知识

提防不靠谱的需求

架构设计--分层架构

定义:把功能相似，抽象级别相近的实现进行分层隔离

优势:松散耦合(易维护、易复用、易扩展)

常见分层方式: MVC、MVVM

架构设计一一模块化

定义: 解决一个复杂问题时，自顶向下逐层把系统划

分成若干模块的过程

意义: 解耦，可并行开发

模块化方案:

AMD,CMD,CommonJS,ES6

模块化方案：AMD是jquery.js 在推广过程中的规范化产出。CMD 是 SeaJS 在推广过程中对模块定义的规范化产出。

AMD:提前执行（异步加载：依赖先执行）+延迟执行

CMD:延迟执行（运行到需加载，根据顺序执行）

我不太喜欢这两个模块化的原因是因为这两个将模块化代码和业务代码掺杂在了一起。CommonJS是服务器端模块的规范，由Node推广使用。模块语义化较少并且与业务也是分开的。ES6它的模块化组织方式与commonjs类似，但由于对于旧版本的兼容性不太友好，我们可以考虑把它放在兼容性比较高的系统上。我们模块化方案定下了commonjs。

架构设计

技术选型，我们一般是调出几个比较主流的方案，然后从中选出稳定性，拓展性，运行速度，开发速率，兼容性等各个方面综合考虑，进行横向对比，最终选出一个相对来说比较合适的方案。

软件过程选择一一敏捷开发

定义: 以用户的需求进化为核心，采用迭代、循序渐进的

方法进行软件开发

而不是概念和工具

是一种迭代的意识和方法，

优点: 能够应对满足不断变化的需求

不足: 对团队成员的能力要求比较高

前后端分离方式-不分离

前后端共用同一项目目录，甚至页面内嵌js、css

本地开发环境搭建成本高

共同维护成本高

发布风险高

前后端分离方式一部分分离

后端负责页面模板(JSP /Velocity /Freemarker)

本地开发环境搭建成本较高

更新页面模板仍需后端协助，效率不够高

需要前后端同时发布

前后端分离方式一完全分离1

方案1: velocity,发布的时候同步到后端

优点: 完全分离，能直接生成动态的模板，利于SEO

缺点: 系统复杂度高、需要前后端同时发布

前后端分离方式一完全分离2

方案2:

纯静态html、完全通过接口做数据交互

优点: 完全脱离后端模板，系统复杂度低

缺点: 不太利于SEO

优化方案: Server Render /蜘蛛定制页面

我们也将采用前后端分离方式一完全分离2。

构建工具 ：Grunt 太过庞大被pass掉

Gulp Webpack之间我们选择天生支持commonjs的webpack

版本控制 svn git

这两个版本几乎不属于同一个时代，差别也比较大，git的分支工具用了就回不去了。

直接选git，谁用谁知道。

刚刚都做了哪些选择?

软件过程: 敏捷开发

前后端分离: 完全分离，纯静态方式

模块化方案: CommonJS + Webpack

框架选择: 用户端jQuery + css、管理系统React + Sass

版本控制: git

发布过程: 拉取代码-> 编译打包-> 发布到线上机器