背景
通常的產品化是指的功能邏輯相同或者略有不一樣，例如軟件a有1,2,3功能，軟件b有2,3,4功能，這就是通用的sass的作法，可是本文討論的是指軟件a的1功能和軟件b的功能部分邏輯相同（50%？）部分邏輯徹底不一樣，例如軟件a有5個字段，軟件b有8個字段，軟件b還須要和系統c對接，其實這種狀況下我的建議是用2套系統來實現，提高基礎的快速開發實現功能，可是筆者公司非要2者複用，因此纔有了本文的思考。數據庫
思考
主要有如下幾點差別：sass
- 數據庫表字段差別
- 數據的分離
- .業務邏輯的差別
解決
- 選1套字段較少的軟件作爲基礎版本，多餘字段用新表擴展存儲，缺點是存儲的時候須要插入多張表，讀取也須要讀取多張表，性能有必定損失；優勢是各個軟件版本獨立性更強，減小耦合。用一個大表，缺點是不一樣軟件版本耦合在一塊兒，之後部署，改bug很容易出錯，例如獨立部署軟件a，可是數據庫會有多餘字段，優勢是讀取數據只須要讀取一張表
- 能夠在每條記錄上加入軟件版本一類的字段的來區分，缺點在於數據存儲都會浪費1個軟件版本字段；優勢在於數據和其餘表獨立無耦合和限制。也能夠經過在記錄數據的關聯字段（例如組織公司等）上加入軟件版本，缺點在於數據和其餘表耦合，組織結構沒法切換，數據處理須要多查次來確認類型；優勢在於數據無需存儲軟件版本字段。我的是推薦在數據上存儲軟件版本，減小耦合和組織機構的複用，可是公司選擇的是組織機構區分。。。
- 有多種狀況，須要分不一樣狀況：
- 邏輯差別較小，僅僅是存儲字段的差別，改造老方法加入差別字段存儲，查詢，修改。缺點耦合嚴重，容易出錯。改造老方法返回各類pk，新方法遠程調用，缺點工做量較大，1個插入拆成1個插入和1個更新，性能有所下降；優勢儘可能減小耦合。
- 邏輯差別較大。改造老方法返回各類pk和業務字段，新方法遠程調用，完成差別邏輯
待解決
服務鏈路加長，若是須要保證數據強一致性，事務是個頭疼的問題，用tcc的話，回滾代碼和邏輯是個災難。 多個軟件和服務耦合在一塊兒，改動會互相影響，性能下降性能
這種狀況仍是強烈建議徹底獨立，這樣耦合在一塊兒後期維護是個災難事務