做電子商務網站，一般都涉及到前後臺，前臺是給使用者用的(營銷+銷售系統)，後臺給公司員工用的(業務支撐系統)。
在專案開發初期，技術負責人往往傾向於，將它們混在一起。我曾經也是這樣，但問題在後期就慢慢凸顯了。
我曾經寫過電子商務網站和企業應用開發的區別(12)，和這個一起看，應該會比較好理解我的觀點。

一、從系統部署的角度考慮
在專案開發階段，因為基本上很少涉及部署(遷移到產品環境)，所以部署問題目前沒有凸顯。
當網站上線後，在網站運營階段(即系統維護階段)，特別是運營一個月後，部署的效率和穩定性，會越來越影響到網站的需求響應性(解決一個網站bug的速度)。

三年前，我開發公司網站時，也是將前後臺合併到一個工程，最後還是不得不分離，只通過資料庫作為前後臺的橋樑。因為你不知道調整一個前臺小功能，是否會影響後臺(迴歸測試?)；你也不知道前臺部署好後，後臺是否會受到影響。

網站上線後，前臺需求的變更還是很頻繁(改進使用者體驗)，因為絕大多數時候是改變頁面展現，並不需要後臺做相應變更。把後臺程式碼重新部署一遍只會帶來隱患。

網站重新部署，一般是選擇凌晨6點左右。而後臺部署，只要不是在白天工作時間就行了。
網站前臺對效能要求很高，系統很可能會因為這個重構。但後臺系統，使用者數量很少，幾乎沒有效能要求。

順便說一下，系統會有大量的Job，如統計、價格更新，這類模組建議不要和Web一起，應該單獨部署。

二、從軟體過程角度
因為網站前臺和後臺業務系統，面向的是完全不同的兩類使用者(消費者和企業員工)，它們的需求和需求獲取過程完全不同。
對於前臺，介面原型即需求，頁面/使用者行為驅動開發。對於後臺，是資料和流程驅動開發：Table+Form+Flow。
也就是說，前臺和後臺，是兩種需求分析和設計人員，甚至是兩種設計師(後臺的介面不要求美觀，很死板，但前臺對設計師要求很高)，再或者是兩種開發人員(如前臺PHP，後臺Flex+Java)。

公司業務人員很容易理清後臺業務，但對前臺使用者的心理和行為的分析，一般都不能勝任。這也是為什麼我要將網站需求分析和設計的工作全部包攬。
三年前，我也是讓業務人員設計網站模組，一塌糊塗。最後還是我自己設計全部介面原型，只需要徵求業務人員的意見，他們不寫任何文件。

面向網際網路使用者的軟體開發方法學，和麵向企業使用者的開發方法學，有著天壤之別。但目前專案組是用同一種模式(企業應用開發過程)，這是很危險和低效的。目前在行業裡還沒有成熟的網際網路軟體開發方法學，只有做過兩類開發，才能總結出經驗和教訓。

三、從軟體開發角度
如果說選擇將前後臺合併，是因為程式碼重用。那麼重用的也只是一些簡單的Domain(pojo)，如Book類。但對於後臺，用到Book類，是比較純粹的Book(如圖書管理)，但裡面卻夾雜著大量的無關的、前臺用到的屬性，如評分、使用者留言、評價、相關圖書、其它使用者購買過的圖書等等，導致後臺維護起來非常困難。
像使用者收藏夾，這一很複雜的核心功能，和後臺業務系統幾乎沒有關係。

如果說前後臺只是重用最簡單的Domain，那這種技術層面的重用又有多大價值呢？像圖書查詢，前臺和後臺的業務邏輯、複雜度完全不是一個級別(前臺更復雜)，沒有任何的重用性。
前臺幾乎都是資料展現(無狀態操作)，後臺主要是資料操作。也就是說，你前臺大量的程式碼都是查詢，和後臺的寫入幾乎沒關係，不存在重用性。

像基礎程式碼庫，如使用者性別、倉庫城市等，主要是後臺，前臺只是用到其中非常小一個子集，完全可以複製方式。

另外，前臺不建議用Hibernate，因為它的優勢在資料持久化，也就是增刪改查的“增刪改”，對於查(List+Detail)，還是原生sql便捷，不拖泥帶水。

我上面只是拋磚引玉，很想聽聽大家的意見

，想必很多人在網際網路公司做應用開發，你們或你們公司大牛是如何處理這個問題的？

原文：http://www.iteye.com/topic/1113741