电子商务网站，前后台是否该分离？

做电子商务网站，一般都涉及到前后台，前台是给用户用的(营销+销售系统)，后台给公司员工用的(业务支撑系统)。

在项目开发初期，技术负责人往往倾向于，将它们混在一起。我曾经也是这样，但问题在后期就慢慢凸显了。

我曾经写过电子商务网站和企业应用开发的区别(12)，和这个一起看，应该会比较好理解我的观点。

一、从系统部署的角度考虑

在项目开发阶段，因为基本上很少涉及部署(迁移到产品环境)，所以部署问题目前没有凸显。

当网站上线后，在网站运营阶段(即系统维护阶段)，特别是运营一个月后，部署的效率和稳定性，会越来越影响到网站的需求响应性(解决一个网站bug的速度)。

三年前，我开发公司网站时，也是将前后台合并到一个工程，最后还是不得不分离，只通过数据库作为前后台的桥梁。因为你不知道调整一个前台小功能，是否会影响后台(回归测试?)；你也不知道前台部署好后，后台是否会受到影响。

网站上线后，前台需求的变更还是很频繁(改进用户体验)，因为绝大多数时候是改变页面展现，并不需要后台做相应变更。把后台代码重新部署一遍只会带来隐患。

网站重新部署，一般是选择凌晨6点左右。而后台部署，只要不是在白天工作时间就行了。

网站前台对性能要求很高，系统很可能会因为这个重构。但后台系统，用户数量很少，几乎没有性能要求。

顺便说一下，系统会有大量的Job，如统计、价格更新，这类模块建议不要和Web一起，应该单独部署。

二、从软件过程角度

因为网站前台和后台业务系统，面向的是完全不同的两类用户(消费者和企业员工)，它们的需求和需求获取过程完全不同。

对于前台，界面原型即需求，页面/用户行为驱动开发。对于后台，是数据和流程驱动开发：Table+Form+Flow。

也就是说，前台和后台，是两种需求分析和设计人员，甚至是两种设计师(后台的界面不要求美观，很死板，但前台对设计师要求很高)，再或者是两种开发人员(如前台PHP，后台Flex+Java)。

公司业务人员很容易理清后台业务，但对前台用户的心理和行为的分析，一般都不能胜任。这也是为什么我要将网站需求分析和设计的工作全部包揽。

三年前，我也是让业务人员设计网站模块，一塌糊涂。最后还是我自己设计全部界面原型，只需要征求业务人员的意见，他们不写任何文档。

面向互联网用户的软件开发方法学，和面向企业用户的开发方法学，有着天壤之别。但目前项目组是用同一种模式(企业应用开发过程)，这是很危险和低效的。目前在行业里还没有成熟的互联网软件开发方法学，只有做过两类开发，才能总结出经验和教训。

三、从软件开发角度

如果说选择将前后台合并，是因为代码重用。那么重用的也只是一些简单的Domain(pojo)，如Book类。但对于后台，用到Book类，是比较纯粹的Book(如图书管理)，但里面却夹杂着大量的无关的、前台用到的属性，如评分、用户留言、评价、相关图书、其它用户购买过的图书等等，导致后台维护起来非常困难。

像用户收藏夹，这一很复杂的核心功能，和后台业务系统几乎没有关系。

如果说前后台只是重用最简单的Domain，那这种技术层面的重用又有多大价值呢？像图书查询，前台和后台的业务逻辑、复杂度完全不是一个级别(前台更复杂)，没有任何的重用性。

前台几乎都是数据展现(无状态操作)，后台主要是数据操作。也就是说，你前台大量的代码都是查询，和后台的写入几乎没关系，不存在重用性。

像基础代码库，如用户性别、仓库城市等，主要是后台，前台只是用到其中非常小一个子集，完全可以复制方式。

另外，前台不建议用Hibernate，因为它的优势在数据持久化，也就是增删改查的“增删改”，对于查(List+Detail)，还是原生sql便捷，不拖泥带水。

我上面只是抛砖引玉，很想听听大家的意见，想必很多人在互联网公司做应用开发，你们或你们公司大牛是如何处理这个问题的？

(广告)如果你对大型电子商务系统的设计和开发，有浓厚的兴趣，不妨看看这里。