方案
每晚我们对大约一百万份客户合同进行一系列计算。每个合同与一组约十个产品中的一个相关，每个产品可以采用要执行的计算集的变化（尽管整体流程大致相同）。给定产品的所有合同将在任何给定的夜晚使用相同的计算集合;虽然从最小的产品几千到最大的几十万，但分布不均匀。
随着时间的推移，我们将添加新的类似（但不太可能相同）的产品，并且可以通过引入所使用的算法的变化来调整现有产品。 （顺便说一句，我希望算法能够在没有代码修改的情况下参数化地改变。）
我们用来支持这一点的核心“引擎”应该适用于产品开发和生产。后者由我们的运营人员管理，他们对他们接受的内容以及如何管理变更非常谨慎。
在考虑建筑时，我强烈关注Open-Closed Principle：
软件实体应该是开放的 延期，但关闭 修改
由于我们计划在C＃中实现，我正在考虑规定函数在核心外部定义，以文本形式加载，并在运行开始时编译，以便在当前版本的控制下生成产品定义。这些组件中的每一个都将编译为实现应用程序的已编译元素中定义的接口（或等效）的类。我乐观地认为，由于回归测试的范围大大减少，因此从操作的角度来看，这将被视为一个优势。
问题
这有意义吗？任何人都可以就潜在的陷阱提供任何圣人建议吗？
我是否正在重新发明依赖注入，我是否会更好地建议通过每次提供新的DLL来提供常规更改？如果是这样，那么我们的日常产品开发过程会有多糟糕呢？
或者我应该采取更敏捷的方法，端到端构建一个产品并依次添加其他产品，看看我重构时出现了什么样的架构？
如果你还在我身边，感谢你的耐心......
答案 0 :(得分：1)
使用依赖注入来创建一个带有获取IProcess参数的进程方法的类。为实现此接口的每个产品类型创建一个不同的类，每个类应该在它自己的DLL中。创建配置文件以将产品类型映射到处理dll和类。然后，您可以使用反射读取配置文件并加载相关的dll，然后将它们传递到DI类的过程函数中。这样，您只需创建一个新DLL并更新配置文件即可添加新进程。更改现有流程只是更新相关类和重新部署DLL的一部分。