设想
每天晚上，我们都会对大约一百万份客户合同进行一系列计算。每份合同都与一组大约十种产品相关，其中每一种产品都可能对要执行的计算集采用变化（尽管总体流程大致相同）。给定产品的所有合同将在任何给定的夜晚使用相同的计算集；分布不均，从最小的几千到最大的几十万不等。
随着时间的推移，我们将添加新的类似（但不太可能相同）的产品，并且现有产品可能会通过对所采用的算法引入变化来进行调整。（顺便说一下，我希望算法能够在不修改代码的情况下进行参数化）。
我们用来支持这一点的核心“引擎”应该适用于产品开发和生产。后者由我们的运营人员管理，他们对他们接受的内容以及一般如何管理变更非常谨慎。
在考虑架构时，我强烈地被开闭原则所吸引：
软件实体应该对扩展开放，对修改关闭。
由于我们计划在 C# 中实现，我正在考虑规定函数在内核外部定义，以文本形式加载并在产品定义的当前版本控制下的产品运行开始时编译. 这些组件中的每一个都将编译为一个类，该类实现在应用程序的已编译元素中定义的接口（或等效接口）。我乐观地认为，从操作的角度来看，这将被视为一个加分项，因为回归测试的范围大大减少了。
问题
这有意义吗？任何人都可以就潜在的陷阱提供任何明智的建议吗？
我是否重新发明了依赖注入，我是否最好通过每次提供一个新的 DLL 来提供定期更改？如果是这样，这会使我们的日常产品开发过程变得更糟吗？
或者我应该采用更敏捷的方法，端到端构建一个产品，然后依次添加其他产品，看看我重构时会出现什么架构？
如果你还在我身边，谢谢你的耐心...