rule-engine - ルールエンジン-長所と短所

Question

ルールエンジンと呼ばれるものを使用するプロジェクトを監査しています。つまり、アプリケーションコードからビジネスロジックを外部化する方法です。

この概念は私にとってまったく新しいものであり、私はそれについてかなり懐疑的です。過去数年間、人々が貧血ドメインモデルについて話しているのを聞いた後、私はルールエンジンアプローチに疑問を投げかけています。私には、それらはドメインモデルを弱めるための素晴らしい方法のように思えます。たとえば、RulesEngineと対話するJavaWebアプリケーションを実行しているとします。次に、同じドメインに基づくAndroidアプリが必要だと判断しました。AndroidアプリがRulesEngineとも相互作用するようにしたい場合を除いて、すでに作成されているビジネスロジックを見逃す必要があります。

私はまだそれらの経験がないので、好奇心だけで、ルールエンジンを使用することの長所と短所について聞いて興味がありましたか？私が考えることができる唯一の利点は、ビジネスルールを変更するためだけにアプリケーション全体を再構築する必要がないということです（しかし、実際には、どれだけのアプリが実際にその数の変更を持っていますか？）。しかし、ルールエンジンを使用してその問題を解決することは、ショットガンの傷にバンドエイドをかけるようなものです。

更新-これを書いた後、神自身、マーティン・ファウラーは、ルールエンジンの使用についてブログに書いています。

Answer 1

私が見たほとんどのルール エンジンは、システム コードによってブラック ボックスと見なされます。ドメイン モデルを構築する場合、オブジェクトに無効な値がある場合に通知するビジネス ルールなど、特定のビジネス ルールをドメイン モデルに組み込みたいと思うでしょう。これにより、ビジネス ロジックを複製することなく、複数のシステムでドメイン モデルを共有できます。各システムで同じルール サービスを使用してドメイン モデルを検証することもできますが、これはドメイン モデルを弱体化させるようです (質問で指摘されているように)。なんで？ビジネス ルールを常にすべてのシステムに適用するのではなく、いつビジネス ルールを適用する必要があるかをシステム プログラマーに判断してもらいます (ルール サービスを呼び出す)。これは、ドメイン モデルが完全に設定されている場合は問題にならない可能性がありますが、次の場合は問題になる可能性があります。

ビジネス ルールには、意思決定という別のクラスがあります。たとえば、保険会社は、申込者を引き受けるリスクを分類し、保険料を計算する必要がある場合があります。これらのタイプのビジネス ルールをドメイン モデルに配置することもできますが、通常は、このようなシナリオに対する中央集中型の決定が望ましく、実際には、サービス指向アーキテクチャに非常に適しています。これは、なぜシステム コードではなく、ルール エンジンなのかという疑問を生じさせます。ルールエンジンがより良い選択となる場所は、意思決定を担当するビジネスルールが時間の経過とともに変化する場所です（他の回答が指摘しているように）。

通常、ルール エンジンを使用すると、システムを再起動したり、新しい実行可能コードを展開したりせずにルールを変更できます (ベンダーからの約束に関係なく、ルール エンジンに問題がなくても、変更を非運用環境でテストするようにしてください。 、人間はまだルールを変更しています）。「データベースを使用して変化する値を保存することでそれができる」と考えているなら、その通りです。ルール エンジンは、何か新しいことを行う魔法の箱ではありません。これは、より高いレベルの抽象化を提供するツールであるため、車輪の再発明に集中する必要がなくなります。多くのベンダーは、ビジネス ユーザーがルール言語を学習する代わりに空白を埋めることができるようにテンプレートを作成できるようにすることで、これをさらに一歩進めています。

テンプレートに関する 1 つの注意事項: テンプレートは、最低限、ルールを記述する必要があるため、テンプレートを使用せずにルールを記述するよりも時間がかかることはありません。より高い初期コストを計画します (データベースを使用して変化する値を保存するシステムを構築する場合と、システム コードに直接ルールを書き込む場合と同じです) - ROI は、システム コードの将来のメンテナンスを節約するためです。 .

Answer 2

貧血ドメインモデルに関するあなたの懸念は有効だと思います.

私が働いている実稼働環境で、有名な商用 Rete ルール エンジンの 2 つのアプリケーションが実行されているのを見てきました。一つは成功、もう一つは失敗だと思います。

成功したアプリケーションは、それぞれが最大 30 の分岐点を持つ最大 10 個のツリーで構成されるデシジョン ツリー アプリです。ルール エンジンには、ビジネス関係者がルールを維持できるようにする UI があります。

あまり成功していないアプリケーションでは、ルール データベースに約 3000 のルールが叩きつけられています。新しいルールが追加されたときに競合するルールがあるかどうかは誰にもわかりません。Rete アルゴリズムはほとんど理解されておらず、製品に関する専門知識が会社を去ったため、変更もリファクタリングも不可能なブラック ボックスになっています。デプロイ サイクルは依然としてルールの変更の影響を受けます。ルールが変更された場合は、完全な回帰テストを実行する必要があります。メモリも問題でした。

私は軽く踏みます。上記の単純な電子メールのサンプルのように、ルール セットのサイズが小さい場合は、変更を簡単に理解できます。ルールの数が数百に達すると、問題が発生する可能性があると思います。

また、アプリケーションでルール エンジンがシングルトンのボトルネックになることも心配です。

ルール エンジン スペースを分割する方法としてオブジェクトを使用することに何の問題もないと思います。プライベート ルール エンジンに従うオブジェクトに動作を埋め込むことは、私には問題ないように思えます。ルール エンジンがオブジェクトの一部ではない状態を適切に起動する必要がある場合、問題が発生します。しかし、それは設計が難しいという別の例にすぎません。

Answer 3

ルール エンジンは、場合によっては多くの価値を提供できます。

まず、多くのルール エンジンはより宣言的な方法で動作します。非常に大雑把な例としては、正規表現をコード ブロックに割り当てることができる AWK があります。ファイル スキャナが正規表現を検出すると、コード ブロックが実行されます。

この場合、たとえば大きな AWK ファイルがあり、さらに別の「ルール」を追加したい場合は、ファイルの最後に簡単に移動し、正規表現とロジックを追加して、次の操作で完了することがわかります。それ。具体的に言うと、多くのアプリケーションでは、他のルールが何をしているのかを特に気にする必要はなく、ルール同士が実際に相互運用することはありません。

したがって、AWK ファイルは「ルール スープ」のようになります。この「ルール スープ」の性質により、人々は、システム内に存在する可能性のある他のすべてのルールをほとんど気にせずに、自分のドメインに非常にしっかりと集中できます。

たとえば、フランクは合計 $1000 を超える注文に関心があるため、関心のあるルール システムに入力します。"IF order.total > 1000 THEN email Frank".

一方、サリーは西海岸からのすべての注文を希望しています: "IF order.source == 'WEST_COAST' THEN email Sally".

したがって、この単純で不自然なケースでは、順序が両方のルールを満たすことができますが、両方のルールは互いに独立していることがわかります。西海岸からの 1200 ドルの注文は、Frank と Sally の両方に通知されます。フランクが気にしなくなったとき、彼は単純に自分のルールをスープから引き離します。

多くの状況で、この柔軟性は非常に強力です。この場合のように、単純なルールのためにエンド ユーザーに公開することもできます。高レベルの式とおそらく軽量のスクリプトを使用します。

さて、明らかに、複雑なシステムではあらゆる種類の相互関係が発生する可能性があります。これが、システム全体が「ルールで完了」していない理由です。誰かが、どこかで、手に負えないルールを担当することになります。しかし、だからと言って、そのようなシステムが提供できる価値が必ずしも低下するわけではありません。

これは、ルールが作成できるデータに対してルールが起動するエキスパート システムのようなものにも当てはまらないことに注意してください。ただし、より単純なルール システムです。

いずれにせよ、この例が、ルール システムが大規模なアプリケーションの強化にどのように役立つかを示していることを願っています。

Answer 4

私が見たルール エンジンの最大の長所は、プログラマーに責任を負わせる代わりに、ビジネス ルールの所有者がビジネス ルールを実装できることです。利害関係者から常にフィードバックを受け取り、迅速なイテレーションを行うアジャイル プロセスがあるとしても、ビジネス ルールを作成する人々にそれらを実装させることによって達成できるレベルの効率を達成することはできません。

また、ルールがコードに埋め込まれている場合、単純なルールの変更によって発生する可能性のある再コンパイル - 再テスト - 再デプロイのサイクルを削除することの価値を過小評価することはできません。多くの場合、ビルドの承認には複数のチームが関与しますが、ルール エンジンを使用すると、その多くを不要にすることができます。

Answer 5

クライアント用のルール エンジンを作成しました。最大の勝利は、すべての利害関係者を含めたことです。エンジンはクエリを実行 (または再生) し、何が起こっているのかをテキストで説明できます。ビジネス担当者は、テキストの説明を見て、ルール、例外、およびその他の特殊なケースのニュアンスをすばやく指摘できます。ビジネス側が関与するようになると、彼らの意見を簡単に得ることができたため、検証ははるかに改善されました。さらに、ルール エンジンはアプリケーション コード ベースの他の部分とは別に存在できるため、複数のアプリケーションで使用できます。

短所は、一部のプログラマーはあまり学びたくないということです。ルール エンジンとそれらに設定するルール、およびそれらを実装するものは、少し複雑になる可能性があります。優れたシステムは、病的でねじれたロジックの網を簡単に処理できますが (または非論理的であることが多い ;)、一連のステートメントをコーディングするほど単純ではありませんif(単純なルール エンジンの一部が何を行っても)。ルール エンジンは、ルールの関係を処理するためのツールを提供しますが、そのすべてを頭の中で想像できる必要があります。時々それは映画ブラジルに住んでいるようなものです. :)

Answer 6

それは（他のすべてと同様に）アプリケーションによって異なります。一部のアプリケーション (通常、変更されないアプリケーションや、実際の定数に基づいたルールが最適なアプリケーション、つまり、物理特性や式など、何年にもわたって著しく変化しないアプリケーション) では、ルール エンジンを使用しても意味がありません。複雑さが増し、開発者はより大きなスキル セットを必要とします。

他のアプリケーションでは、これは本当に良い考えです。たとえば、注文処理 (請求から通貨取引の処理までの注文) を例にとると、新しい要件 (たとえば、消費税など) を満たすことを要求する、関連する法律またはコード (司法上の意味で) がわずかに変更されることがあります。 、古典）。以前のように突然消費税について考えなければならないこの新しい状況に古いアプリケーションを無理やり押し込もうとするよりも、潜在的に大きな問題に干渉するよりも、ルール セットを適応させる方が簡単です。あなたのコードのセット。

次に、地方自治体からの次の改正では、特定の基準内ですべての売上を報告することが義務付けられており、それを追加する必要はありません。最終的には非常に複雑なコードになってしまい、他のすべてのルールに影響を与えることなく、ルールの 1 つの効果を元に戻したい場合に、管理が非常に難しくなります...

Answer 7

これまでのところ、誰もがルール エンジンについて非常に肯定的でしたが、読者には用心することをお勧めします。問題が少し複雑になると、突然、ルール エンジン全体が不適切になったり、より強力な言語よりもはるかに複雑になったりすることがあります。また、多くの問題では、ルール エンジンは、条件を評価するための実行時間とメモリ フットプリントを大幅に削減するプロパティを簡単に検出できません。依存性注入フレームワークやより動的なプログラミング言語よりもルール エンジンを好む状況は比較的少ないです。

Answer 8

「しかし、実際には、これほど多くの変更が加えられたアプリがいくつあるでしょうか?」

正直なところ、私が取り組んできたすべてのアプリは、コンセプトから展開後まで、ワークフローやロジックの大幅な変更を経てきました。それが「メンテナンス」プログラミングの最大の理由です...

現実には、すべてを前もって考えることはできないため、アジャイル プロセスが必要になります。さらに、BA は、テストで発見されるまで、常に何か重要なものを見落としているようです。

ルール エンジンを使用すると、ビジネス ロジックをプレゼンテーションやストレージから完全に分離する必要があります。さらに、適切なエンジンを使用している場合、BA は必要に応じてロジックを追加および削除できます。Chris Marasti-Georg が言ったように、BA に負担がかかります。しかしそれ以上に、BA は彼らが求めているものを正確に得ることができます。

Answer 9

すでにたくさんの良い答えがありますが、いくつか追加したいと思いました。

1. 複雑さの決定を自動化する上で重要なことは、関連するロジックを実行するのではなく、管理する能力になります。ルールエンジンはこれを支援しません-あなたはビジネスルール管理システムが持っているルール管理機能について考える必要があります。ほとんどの商用およびオープンソースのルールエンジンは、リポジトリを備えたルール管理システムに進化し、ルールの使用状況やバージョン管理などをレポートします。ビジネス上の意思決定を行うために調整できる一貫したルールセットに構造化されたルールのリポジトリは、どちらよりも管理がはるかに簡単です。数千行のコードまたはルールスープ。
2. 宣言型のルールベースのアプローチを使用する方法はたくさんあります。ルールを使用してUIを管理したり、プロセスの定義の一部として使用したりすると、非常に効果的です。ただし、ルールアプローチの最も価値のある使用法は、ビジネス上の意思決定を自動化し、これを、入力を受け取り、ルールを実行し、回答（決定）を返す緩く結​​合された意思決定サービスとして提供することです。これらは、「この顧客は信用リスクが高い」、「この注文に対してこの顧客にどのような割引を与えるべきか」、「現時点でこの顧客にとって最良のクロスセルは何か」などの他のサービスの質問に答えるサービスとしてのものです。これらの意思決定サービスは、ルール管理システムを使用して非常に効果的に構築でき、時間の経過とともに分析を簡単に統合できます。これは、多くの意思決定から恩恵を受けるものです。

Answer 10

ルール エンジンは、回避できる場合はカスタム ビルドを実行する必要がない構成可能なアプリケーションに適しています。また、ルールの大規模なベースを一元化することにも優れており、Reteのようなアルゴリズムは、大規模なルール セットに対して迅速に照合するのに効率的です。

Answer 11

ルール、プロセス、データエンジン（別名データベース）は本質的に類似していると思います。しかし、何らかの理由で、永続性サブシステムのブラックボックス化が悪いとは決して言えません。

第二に、私のPOVから、貧血モデルは行動の実装において軽いモデルではなく、行動自体において軽いモデルです。ドメインモデルオブジェクトで使用可能な動作を記述する実際のメソッドは、オブジェクト自体で実行する必要はありません。