在基於網絡的項目上工作的業務規則和邏輯需要由客戶自定義。我想這樣做，而不必每次我們在系統上註冊新客戶端時重新編譯應用程序。到目前爲止我所概述的架構如下：
你有沒有實現過類似的東西？如果是這樣，你的經驗是什麼？最後還有另一個我應該探索的解決方案嗎？
感謝您的幫助！
我實施了大部分您提到的方法。答案可能取決於各種因素。
客戶角色將對業務規則進行更改（例如，業務分析師，開發人員，高級用戶等）？對業務分析師的有意義的支持可能需要一個規則引擎，在數據庫和可用的用戶界面中具有外化規則。對開發者的有意義的支持可能像利用MEF（http://www.codeplex.com/MEF）這樣的簡單操作。
您可能還需要考慮業務規則需要更改的頻率以及可能適用的關聯操作要求的類型（例如，主機進程必須保持運行，應用程序域卸載正常等）。一個好的選擇可能需要仔細考慮可能的未來需求。
您可以執行數據驅動的業務規則，如this。決策樹也是一個很好的方法。
您也可以將面向方面的編程思考爲實現業務規則的一種方式。
我唯一對Rete感應規則引擎的警告是規則集應該保持很小並且靠近使用它們的對象。如果你可以將對象的行爲封裝在屬於其狀態一部分的規則引擎中，那就更好了。我不關心「企業」解決方案，它將成千上萬的規則轉儲到單一規則引擎中，併成爲企業每個部分的依賴關係。
這可能不是最好的方法，但是我的公司在幾種情況下實現了你的＃2選項，並取得了成功。
我們基本上將客戶端配置在數據庫或配置文件中，並且對於每個客戶端，都會有一個查找表，存儲類名稱以調用要執行的任何業務操作。當代碼獲得客戶端A的請求時，它查找要使用的類，並創建它並通過反射執行它。
我不是一個將代碼相關的東西放在數據庫中的巨大粉絲，但它確實可以正常工作，在這種情況下不會太複雜。
我創建了一個基於以下開源.NET業務規則引擎NxBRE的動態規則引擎。我使用Flow引擎作爲我的動態規則引擎的主要示例。
我使用了與您的問題中提到的相同的架構。
我建議1和3
的組合，但不要將工作流程存儲在數據庫中，存儲是一個決策樹或規則流（我們叫他們）。
當您擁有一個可視化的，動作驅動的工具（如Visual Rules）時，更改工作流以適應特定的客戶或將它們聯合到其配置文件中是一項簡單的任務。讓您的業務分析師或支持人員進行更改也有很多好處，而無需調整代碼。
也沒有這些要求需要複雜的AI工具，如RETE和推理 - 順序邏輯是最好的。