1年多了，完全這個文集的事忘記的一干二凈了，直到今天，偶然瀏覽一下自己簡書的文章??。

這一年多的時間我們的產品陸陸續續發生了很多事情?！肝⒖投唷巩a品「已死」，或者換一種方式叫「重生」。

因為跟騰訊的某種關系我們代理了騰訊高朋旗下的微商產品（我們就叫項目 W），這個產品完全是新項目，重新組隊招人做。但是人很難找，不排除公司給的工資比市場低的可能。最后放低要求招到了4-5個人，然后開始干活。

項目借鑒「微客多」，但是優化了以前的表結構，架構。但是實際上很多功能都是「微客多」做完之后，「項目 B」重新 Copy 過來，做一些重復性的工作。

剛開始「項目 B」可能改的不錯，但是后來估計也是項目時間進度緊張，有些地方就懶得改了。

隨著每份需求可能要做兩邊，然后開始考慮做兩個項目合并的事情，合并之后好出多多，這就是所謂的平臺架構。

但是合并說起來容易，做起來真的很難，難是的是數據遷移問題。于是從開始合并之后，「微客多」只修改 bug，不做新需求。前兩個月可能改一下 bug，后面基本上沒動過微客多的代碼了。

合并之后的項目，代碼只有一份了，好維護，用戶登錄之后會根據不同的平臺標識顯示不同的 LOGO，不同的平臺，價格是不一樣的，打著高朋團購的牌子當然要貴的多。

一個 SAAS 平臺不可避免的會出現定制單，因為一個產品不可能滿足所有的需求。

定制單我們的怎么做的呢？還是把主項目代碼 Copy 一份過來改，然后這樣后面就會導致一個問題，我們的主項目一直再快速的更新迭代做新需求，越到后面，代碼和定制單差距越大，然后有一天我們的定制客戶突然想用我們的主項目新功能了怎么辦？還能怎么辦？重寫唄。

其實我們還有一個好辦法，我們把公司的業務模塊拆開來做，每一個模塊都做成一個獨立的項目，支持其他平臺，這里的平臺包括定制單。比方說我們做一個交易中心專門負責微信支付有關系的接口實現（包括微信發紅包，微信退款），我們的郵箱系統，我們的 CDN 系統還有硬件系統，都按照支持多平臺來設計架構。

數據是怎么打通的呢？可以使用接口，內網訪問保證速度，有些接口保證必要的鑒權。