非常にスケーラブルで動的な「ルールベースの」アプリケーション？
大規模なエンタープライズアプリの場合、変更に対応できることがデザインの最も重要な側面の1つであることは誰もが知っています。ビジネスロジックの変化に対応するために、多くの場合、ルールベースのアプローチを使用しており、各ルールはDBに格納されています。これにより、厄介な詳細に飛び込むことなく簡単に変更を加えることができます。 C＃はEval（ "foo（bar）;"）を実行できないため、これは行に格納されたフォーマットされた文字列を使用して実行され、実行時にJavaScriptで処理されます。これは問題なく機能しますが、エレガントではなく、レガシーになると、他の誰にとっても最も楽しいものではありません。
これに対するよりエレガントな解決策はありますか？かなり頻繁に変更される何千ものルールに遭遇すると、それは本当のことになりますが、これは、誰かがこれを行うためのより良い方法を考えていない問題の珍しいことではありません。助言がありますか？この現在の方法は防御可能ですか？代替案は何ですか？
編集：明確にするために、これは大規模なエンタープライズアプリであるため、どのソリューションが機能しても、ルールとデータを常に維持している人はたくさんいます（約10）。また、データは頻繁に変更されるため、ある種の集中サーバーシステムは基本的に必須であると言えます。
プログラマー以外がビジネスルールを開発するために使用できる抽象化を作成しようとしている場合は、WFまたはDroolsを使用します。ただし、=の抽象化よりもプログラマーを扱う場合はWFソリューションを開発するのにかかる時間の価値はありません。投資の付加価値を確認できません。
データベースは、大幅に変更される可能性のあるルールを維持するための優れた方法ですが、可能な代替案を提案させてください（必ずしも優れているわけではありませんが、代替案です）。
1）ビジネスロジックを独自のレイヤー（dll）に分離します-いくつかのインターフェイスで呼び出す方法を抽象化します（戦略とオブザーバーのパターンを見てください）、つまりIRuleEvaluator.Evaluate（string myParams）。
2）これで、各ルール（必要な場合）および付随する単体テストに対して個別のクラスを作成できます。
3）次に、Piècederésistanceのために、IOCコンテナー-dllとルールエバリュエーターインスタンス自体で、シーンの背後にあるすべてのものを接続します。このように、ルールエバリュエーターは、ランタイム-一緒にハードコードされているものはありません。
このアプローチは非常に動的です（一部のテイストでは動的すぎる可能性があります）。これにより、すべてのルールに対して実際の個別のユニットテストを実行できます。ルールを再デプロイまたは変更する必要がある場合は、新しいDLLを削除し、IOC構成ファイルを変更し、再起動して確認します。または、問題がある場合は変更をロールバックします。コアコードを変更することなく（データベースのように）、データベースとは異なり、ロジックとアプリケーションコードを1つにまとめるのではなく、半分をC＃で記述し、半分をSQLで記述します。
私が見たルールには2つのケースがあります。ほとんどの場合、ルール自体は非常に不安定ではありません（ほとんど固定されています）が、ビジネスユーザーは決定を行うデータを変更できます。この場合、データベースから参照データを読み取ることで各ルールをカプセル化する単純な設計パターンで通常は十分です。次に、ルール参照データを変更するためのフロントエンドを提供します。
ルールロジック自体を動的に変更できるその他のケース。 1つのアプローチは、IronPythonまたは他の動的言語（.Net 4内）を使用してルールを実装し、実行時に動的にロードすることです。プログラマがルールを変更する必要があるため、これは妥協です。
ビジネスユーザーがルールを編集できるようにしたい場合は、ビジネスドメイン用のDSLを作成することをお勧めします。しかし、これは複雑な作業です。
最後に、ワークフローまたはBizTalkを使用すると、ルールが変換/オーケストレーションパターンに適合する場合に役立ちます。
ルールがビジネスから頻繁に変更される高度にスケーラブルな「ルールベースの」アプリケーションを設計している場合は、次のような市場をリードするBRMS製品を検討してください。1. IBM WODM 2. FICO BLAZE Advisor 3. Drools（オープンソース）
私は、BRMSアプローチを使用して大規模な商用アプリケーションに取り組んできました。これにより、アプリケーションのスケーラビリティが高く、保守が容易になり、生産までのダウンタイムがゼロになり、非常に柔軟になります。それはビジネスを幸せにします。 :)
頭に浮かぶのは Windows Workflow Foundation です。これはASP.NETと一緒に使用できますが、サーバー側で実行されます（そのため、実行していることには適用されない可能性があります）。 Java Landには jBPM （ビジネスプロセス管理）があり、サーバー側でも実行されます。
これらのソリューションはおそらくあなたのための法案に合わないので、最善のことはそれらのビジネスルールをプレーンな古いコードで実装することです（JavaScriptを使用する） 、C＃、または仕事に最適なもの）、設計変更が発生したときにプログラミングコードを更新する必要があることを期待します。オブジェクト指向の設計パターンを使用すると、コードを簡単に拡張できます。コードをうまく書けば、将来それを変更するのに必要な労力は最小限に抑えられます。
私はあなたがクライアント側の操作に厳密に言及しておらず、c＃について言及して以来.Netにいると想定しています...
フレームワーク4を使用している場合は、DLR（動的言語ランタイム）があるか、SQLにルールを格納している場合は任意のフレームワークでルールをそこで処理するか、常に> 3フレームワークで動的linqを使用するか、さまざまな関数を記述することができますアセンブリのロードを通じて実行時に名前でロードできるアセンブリとして。
それらのすべてが多くの場合エレガントではありませんが、私はそれらすべてを時々使用しなければなりませんでした。
ルールがすべてフォームの場合
if <condition>
then <action>
[else <action]
Drools.NETまたはiLogなどの別のRete実装を使用できます。