我一直在研究一系列具有相关功能的应用程序，每个应用程序都是为不同的客户提供的。这些应用程序具有大量共同的功能，但每个客户的要求都有一些独特的功能，这些功能无法提供给任何其他客户。
因为到目前为止属于我们客户的所有版本（A1，B2，A3）都是按照每个案例的顺序进行资助和开发的，我们只是简单地拍摄了先前客户的快照，将其放入新的SVN存储库并开始从那里做出改变。到目前为止我们已经管理好了，但预计未来会有更多客户，并计划将客户A3应用程序的一些改进推回到A1的新版本，我们目前的设置无法通过我们当前的流程进行管理
我正在寻找的是有关如何在其他地方完成此类事情的信息，以及我们继续进行的最佳方式。我将描述我对如何处理我对此的担忧以及正在寻找反馈意见的想法。
我们设想根据一些高级别的能力差异将客户分为两大类。我的客户ID前缀为A和B，这反映了这一点; A1和A3的软件版本比B2的版本更为常见。目前我们不希望有一个C类别被添加，但不能排除从现在开始改变几年。
我们的基本思想是将功能的公共部分（后端和win表单类）分成A和B类客户的通用核心库;然后继承公共类并在单独的解决方案中为每个版本实现客户特定的功能。我们可能还有一个顶级公共库，用于与A和B共享的东西，尽管A和B之间存在足够的差异，我担心我们最终会覆盖足够的方法，最终只会增加复杂性情况。
我认为我需要将每个客户应用程序放入单独的解决方案而不是单一解决方案而只选择运行哪些客户应用程序的原因有几个：
首先，由于客户特定的NDA，我们可能会有新的开发人员不允许访问之前完成的应用程序，因为如果没有他们的任务来处理客户X的应用程序，他们无法满足外部强制要求了解NDA批准的要求。
第二，因为我们直接在特定客户的资金上工作，我们无法对公共库功能进行更改（例如，将某些内容从客户特定的内容转移到核心版本或副版本），然后更新每个客户特定的应用程序继续使用新核心。这种约束很大程度上是我们最初采用独立维护的代码库概念的原因，并且有可能验证我们在合同级别上将常见功能和客户特定功能分开的“正确性”。
第三个与第二个有关。出于安全原因，如果客户X不能使用功能Y，则X的应用程序无法在公共库中实现Y，即使X的应用程序没有任何方法可以调用该方法，因为如果他们足够聪明他们可以做反向工程编写自己的前端，位于公共库的顶部。
编辑：这个问题似乎主要在这里消失，但我确实在another site.上得到了相当多的讨论
答案 0 :(得分：1)
我没有遇到相当这种情况，但希望这会有所帮助。
我认为你正在努力让客户保持独立的解决方案;重复代码可能在开发时最初是额外的工作 - 但是当管理依赖性误入歧途时，你可以进入的悲伤程度仍然存在 - 以及首先必须管理它们的开销。
我会记住Stable Abstractions Principle和Stable Dependencies Principle：将尽可能多的常见和低级代码放入库中，这些代码不会改变太多，而且会更具有政治敏感性（并且具有政治敏感性） ）包可以参考。
对我而言，提供低级“编码”的“库”代码或系统级服务（保存文件，访问混乱等）和纯业务逻辑代码/模块之间存在重要区别。所以我认为这里有一些明智的再利用是可以接受的。
与SAP和SDP一致的是尽可能抽象出实现的方法：依赖倒置和策略模式在这里会有所帮助。
虽然您所做的不是多租户应用程序，但我认为您可能会发现一些常见问题 - 并希望有一些有用的解决方案或方法。
我在这里提出的所有建议似乎都在代码/架构/模式层面 - 我知道我没有在实际的代码管理/ QA /发布方面做过很多工作 - 抱歉。