在基于网络的项目上工作的业务规则和逻辑需要由客户自定义。我想这样做，而不必每次我们在系统上注册新客户端时重新编译应用程序。到目前为止我所概述的架构如下：
你有没有实现过类似的东西？如果是这样，你的经验是什么？最后还有另一个我应该探索的解决方案吗？
感谢您的帮助！
我实施了大部分您提到的方法。答案可能取决于各种因素。
客户角色将对业务规则进行更改（例如，业务分析师，开发人员，高级用户等）？对业务分析师的有意义的支持可能需要一个规则引擎，在数据库和可用的用户界面中具有外化规则。对开发者的有意义的支持可能像利用MEF（http://www.codeplex.com/MEF）这样的简单操作。
您可能还需要考虑业务规则需要更改的频率以及可能适用的关联操作要求的类型（例如，主机进程必须保持运行，应用程序域卸载正常等）。一个好的选择可能需要仔细考虑可能的未来需求。
您可以执行数据驱动的业务规则，如this。决策树也是一个很好的方法。
您也可以将面向方面的编程思考为实现业务规则的一种方式。
我唯一对Rete感应规则引擎的警告是规则集应该保持很小并且靠近使用它们的对象。如果你可以将对象的行为封装在属于其状态一部分的规则引擎中，那就更好了。我不关心“企业”解决方案，它将成千上万的规则转储到单一规则引擎中，并成为企业每个部分的依赖关系。
这可能不是最好的方法，但是我的公司在几种情况下实现了你的＃2选项，并取得了成功。
我们基本上将客户端配置在数据库或配置文件中，并且对于每个客户端，都会有一个查找表，存储类名称以调用要执行的任何业务操作。当代码获得客户端A的请求时，它查找要使用的类，并创建它并通过反射执行它。
我不是一个将代码相关的东西放在数据库中的巨大粉丝，但它确实可以正常工作，在这种情况下不会太复杂。
我创建了一个基于以下开源.NET业务规则引擎NxBRE的动态规则引擎。我使用Flow引擎作为我的动态规则引擎的主要示例。
我使用了与您的问题中提到的相同的架构。
我建议1和3
的组合，但不要将工作流程存储在数据库中，存储是一个决策树或规则流（我们叫他们）。
当您拥有一个可视化的，动作驱动的工具（如Visual Rules）时，更改工作流以适应特定的客户或将它们联合到其配置文件中是一项简单的任务。让您的业务分析师或支持人员进行更改也有很多好处，而无需调整代码。
也没有这些要求需要复杂的AI工具，如RETE和推理 - 顺序逻辑是最好的。