背景
通常的产品化是指的功能逻辑相同或者略有不一样，例如软件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的话，回滚代码和逻辑是个灾难。 多个软件和服务耦合在一块儿，改动会互相影响，性能下降性能
这种状况仍是强烈建议彻底独立，这样耦合在一块儿后期维护是个灾难事务