私たちのシステム (エキゾチックな商品デリバティブ取引のキャプチャとリスク管理) は、まもなく再開発されます。私が聞いた提案の 1 つは、ルール エンジンを組み込んで、エンド ユーザー (非常に洗練されたコモディティ トレーダー) がビジネス ロジックに特定の変更を加えやすくするというものです。
私はルールエンジンに少し懐疑的です。私のアジリストは、プロセスの問題に対する技術的な解決策にすぎないのではないかと考えています... つまり。開発者がビジネスの変化の必要性に対応するには時間がかかりすぎます。この問題の解決策は、開発へのより協調的なアプローチ、より優れたテスト カバレッジ、よりアジャイルなプラクティスである必要があります。
ルール エンジンが真に恩恵をもたらす状況 (特に取引環境で) について聞くことは、確かに役立つでしょう。
Fair Issac の Blaze Rete エンジンを使用した 2 つのアプリケーションを見てきました。
1 つのアプリケーションが何千ものルールを 1 つのナレッジ ベースにまとめ、メモリに深刻な問題を抱え、ほとんど理解できないブラック ボックスになってしまいました。私はそれを成功とは言いませんが、本番稼働中です。
別のアプリケーションでは、デシジョン ツリーを使用して、クライアントを処分するための医療フォームに数百の質問を表示しました。これは非常にエレガントに行われたため、開発者を関与させることなく、ビジネスの人々が必要に応じてルールを更新できます。(ただし、まだ 1 つずつ展開する必要があります。) 私はそれを大成功と呼んでいます。
したがって、問題がどれだけ焦点を絞っているか、ルールセットのサイズ、開発者の知識に依存します。私の偏見は、単純にルール エンジンを単一障害点にして、そこにルールをダンプすることは、おそらく良いアプローチではないということです。データ駆動型またはテーブル駆動型のアプローチから始めて、ルール エンジンが必要になるまでそれを拡張しました。また、ルール エンジンをオブジェクトの動作の一部としてカプセル化することも目指しています。ルール エンジンをユーザーから隠し、ルール スペースをドメイン モデルに分割しようとします。
それらが本当に恩恵であると言えるかどうかはわかりませんが、確かに価値があると思います. 私は保険業界で数年間システムに取り組みました。このシステムでは、ビジネス ユーザーが州に応じてどのポリシーが合法であるかを決定するルールを作成できるようにするルール エンジンが非常にうまく採用されました。
たとえば、特定の州で自己負担が必要な場合、または免責額と自己負担の特定の組み合わせが許可されていない場合は、製品の考慮事項のため、または州法により単に違法であったためです.
会社が事業を行っている州の数と、規則の絶え間ない変更 (四半期ごと) を考慮すると、これは目まぐるしいコーディング作業になります。さらに重要なことに、それはプログラマーの専門知識ではありません。これにより、エンド ユーザーが保険業界の専門家ではないプログラマーに対して、適用するルールを説明する無意味なコミュニケーションが追加されます。
正しく設計されたルール エンジンは、適切なテストを可能にするワークフロー システムを有効にすることができます。この場合、ルールはデータベースに保存され、QA データベースと PROD データベースがありました。したがって、BA は QA でルールをテストしてから、PROD に昇格させることができます。
何でもそうですが、それは通常、実装に関するものであり、実際のテクニックに関するものではありません。
はい、Microsoft は BizTalk にビジネス ルール エンジン (BRE) を搭載しており、長年にわたって使用されてきました。BRE のためだけにクライアントに BizTalk (非常に高価) を購入してもらったと聞いています。
私の経験では、ビジネス ユーザーにルールを更新させることの実用性はほとんどありません。通常、ビジネス ルール エディタを操作するには技術者が必要です。
ルール エンジンは、宣言ステートメントを実行するものにすぎません。これらには、主に 2 つの利点があります (私はそう思います)。
すべてではないにしても、ほとんどのルール エンジンは、ルール エンジンを使用しない最適なプログラムを作成する場合よりも多くのオーバーヘッドを追加すると思います。これは、一般に、アセンブリでコードを記述する方がコンパイラよりも高速であることに似ています (ただし、より高いレベルの抽象化を使用する方が便利で生産的であるため、通常はアセンブリを記述しません)。
ここでやめるとしたら、おそらくプログラマーを使用してルールを維持し、ルール エンジンを使用して、アプリケーション内にビジネス ロジック層を構築する便利な方法になるでしょう。一部のルール エンジンは、ルールのテンプレートを定義できるテンプレートと呼ばれるものを提供します。ここでの利点は、技術者以外のユーザーが独自のルールを作成し、既存のルールを変更できることです。
ルール エンジンは、適切に使用すれば価値のある、ツール ボックスのもう 1 つのツールです。
これらのルールエンジンの多くに伴う問題は、速度の欠如と、ルールを置き換えたり拡張したりすると、既存の作業ルールが微妙に破られる可能性があるという事実です。したがって、ルールを変更するたびに、システムを徹底的に再テストする必要があります。つまり、基本的には、あるコンピューター言語を別のコンピューター言語に交換するだけです。つまり、ユーザーベースがはるかに少ないコンピューター言語です。別のポスターが述べたように、私はビジネスアナリストがルールエンジンをうまく使用しているのを見たことがありません。とにかくプログラマーが必要です。
私はこの分野で多くのベンダーと仕事をしていますが、これについての素晴らしいことの 1 つは、多くのベンダーの顧客と話をできることです。そうです、そうです、何百もの企業が約束どおりの利益を得ています。俊敏性の向上、ビジネスと IT のコラボレーションの向上、規制順守の容易化、意思決定の一貫性の向上、メンテナンス コストの削減、市場投入までの時間の短縮などです。
多くのルール、大幅に変更されるルール、複雑な方法で相互作用するルール、または高度なビジネス ドメイン コンテンツ - ビジネス ルール管理システムが機能します。
本当。
私は確かに持っていますが、それらについて公に話すことはできませんが、おそらくあなたは今年何回かやり取りしたことでしょう ;)
ロジック プログラマーとビジネス ユーザーの 2 つのグループに分けられます。ツールが異なれば、対象となるセットも異なります。両方を対象とするものもあります。ビジネス ユーザーの成功例は、それがロジックのサブセットである場合にのみ機能し、テスト ケースを定義して自分で実行する方法も持っていました (そして、論理的に考える準備ができています)。ロジック プログラマーはまれですが、非命令型プログラミングのバックグラウンドを持っていることがよくあります (関数型プログラミングを直感的に理解できる人でもあります)。
結局のところ、ビジュアル ツールを使用する場合でも、コンピューターに何かを実行するように指示している場合は、コンピューターがまだプログラミング中であることに注意してください。
信用格付けはありますか？おそらくFICOスコア？Blaze ルール エンジンの開発者であるF air I saac CO rporationです。
ルール エンジンは、保険ビジネスで日常的に使用されています。私は、ルール エンジンに実装された数百 (600 程度) のルールを持つシステムに取り組んできました。とてもうまくいきました。
私の経験は、(i)あまりない、(ii)プロローグに限られています。しかし、規則エンジンは、手続き型コードよりもはるかに簡潔に命題概念を表現するのに役立つと言っても過言ではありません。
しばらくの間、大規模で大量の大気データを計算するためのシステムを開発する PEATE 分散コンピューティング プロジェクトで働きました。このシステムには、データ マネージャー、スケジューラー、アルゴリズム実行コンポーネントの 3 つの部分がありました。これらのコンポーネントはいくつでも存在する可能性があり、すべて Web サービスを介して実行されますが、さまざまな研究者が任意のデータに対して任意のジョブを実行できるようになり、要件の変更に応じてさまざまなスケジューリング メカニズムをプラグインできるようになりました。
私はプロジェクトが軌道に乗る前に離れましたが、これはシナリオに適合する可能性があり、ある種のルール エンジンの別の例として役立つようです。そうは言っても、元の開発者がまだアルゴリズムを実行する側である場合、各ルールまたはアルゴリズムが被るかなりのオーバーヘッドを処理しない限り、ルール エンジンを使用する利点はあまりないと思います。それは自分のものです。
これは単純なルール エンジンよりも少し複雑に思えますが、このようなアーキテクチャはルール エンジンにも適用できる可能性があります。