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

StackOverflow https://stackoverflow.com/questions/250403

  •  05-07-2019
  •  | 
  •  

質問

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

この概念は私にとってまったく新しいものであり、私はそれについてかなり懐疑的です。過去数年間、人々が Anemic Domain Models について話しているのを聞いた後、ルールエンジンアプローチ。私にとって、それらはドメインモデルを解放する素晴らしい方法のように思えます。たとえば、Rules Engineと対話するjava webappを実行しているとします。次に、同じドメインに基づいてAndroidアプリを作成することにしました。 Androidアプリもルールエンジンとやり取りしたい場合を除き、ビジネスロジックが既に記述されているものを逃す必要があります。

私はまだ好奇心だけでまだ経験がないので、ルールエンジンを使用することの長所と短所について知りたいと思いましたか？私が考えることができる唯一の長所は、いくつかのビジネスルールを変更するためだけにアプリケーション全体を再構築する必要がないということです（しかし、実際にいくつのアプリがそんなに多くの変更を持っていますか？）。しかし、Rules Engineを使用して、散弾銃の傷にバンドエイドをかけるような、この種の問題を解決します。

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

役に立ちましたか？

解決

私が見たルールエンジンのほとんどは、システムコードではブラックボックスと見なされます。ドメインモデルを作成する場合、特定のビジネスルールをドメインモデルに固有のものにしたいでしょう。オブジェクトに無効な値がある場合に通知するビジネスルール。これにより、ビジネスロジックを複製することなく、複数のシステムでドメインモデルを共有できます。各システムで同じルールサービスを使用してドメインモデルを検証することもできますが、これはドメインモデルを弱めるように見えます（質問で指摘したように）。どうして？常にすべてのシステムにビジネスルールを一貫して適用するのではなく、システムプログラマーに頼って（ルールサービスを呼び出して）ビジネスルールを適用するタイミングを決定しているためです。ドメインモデルが完全に読み込まれている場合、これは問題にならないかもしれませんが、ドメインモデルの値をその存続期間にわたって変更するユーザーインターフェイスまたはシステムを扱っている場合は問題になる可能性があります。

別のクラスのビジネスルールがあります：意思決定。たとえば、保険会社は、申請者を引き受けるリスクを分類し、保険料を支払う必要がある場合があります。これらのタイプのビジネスルールをドメインモデルに配置することもできますが、通常、このようなシナリオの一元的な決定が望ましく、実際にはサービス指向アーキテクチャに非常によく適合します。これは、なぜシステムエンジンではなくルールエンジンなのかという疑問を抱いています。ルールエンジンの方が適している可能性があるのは、意思決定を担当するビジネスルールが時間とともに変化する場所です（他のいくつかの答えが指摘しているように）。

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

テンプレートに関する別の注意：テンプレートは、少なくともテンプレートを使用してルールを記述する必要があるため、テンプレートを使用せずにルールを記述するよりも時間がかからないことはありません。より高い初期コストを計画する（データベースを使用して、変更する値を格納するシステムを構築する場合と、システムコードに直接ルールを記述する場合と同じ）-ROIは、システムコードの将来のメンテナンスを節約するためです。

他のヒント

貧血領域モデルに関する懸念は妥当だと思います。

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

成功したアプリケーションは、それぞれが〜30の分岐点を持つ〜10個のツリーで構成される決定木アプリです。ルールエンジンには、ビジネスマンがルールを維持できるUIがあります。

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

軽く踏みました。ルールセットのサイズが控えめな場合、上記の単純な電子メールサンプルのように、変更を理解するのは簡単です。ルールの数が数百に上ると、問題があるかもしれません。

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

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

ルールエンジンは、特定のインスタンスで多くの価値を提供できます。

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

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

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

たとえば、フランクは合計$ 1000を超える注文に興味があるため、興味のあるルールシステムに参加します。 ＆quot; IF order.total＆gt; 1000 THEN電子メールフランク＆quot;。

一方、サリーは西海岸からのすべての注文を求めています：＆quot; IF order.source == 'WEST_COAST' THEN email Sally＆quot;。

それで、この些細で不自然なケースでは、注文は両方のルールを満たすことができますが、両方のルールは互いに独立していることがわかります。西海岸からの1200ドルの注文は、フランクとサリーの両方に通知します。フランクが心配しなくなったら、スープからルールを削除します。

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

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

これは、ルールが作成できるデータに対してルールが発動するエキスパートシステムのようなものではなく、よりシンプルなルールシステムにも当てはまります。

とにかく、この例が、ルールシステムがより大きなアプリケーションの拡張にどのように役立つかを示してくれることを願っています。

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

また、ルールがコードに埋め込まれている場合、単純なルール変更の結果として発生する可能性のあるrecompile-retest-redeployサイクルを削除する際に値を強調することはできません。多くの場合、ビルドに祝福をかけることに関与しているチームがいくつかあり、ルールエンジンを使用すると、その多くが不要になります。

クライアント用のルールエンジンを作成しました。最大の勝利は、すべての利害関係者を含むことでした。エンジンはクエリを実行（またはリプレイ）し、テキストで何が起こっているかを説明できます。ビジネスマンは、テキストの説明を見て、ルール、例外、およびその他の特殊なケースのニュアンスをすばやく指摘できます。ビジネス側が関与すると、入力を取得するのが簡単だったため、検証はずっと良くなりました。さらに、ルールエンジンはアプリケーションコードベースの他の部分とは別個に使用できるため、アプリケーション全体で使用できます。

欠点は、一部のプログラマーはあまり学びたくないということです。ルールエンジンと、それらに実装するルール、およびそれらを実装するものは、少々毛深いものです。優れたシステムは、病気やねじれたロジックのウェブ（またはillogicの多くの場合;行う）。ルールエンジンには、ルールの関係を処理するツールが用意されていますが、それでもすべてを想像する必要があります。時々、映画に住むようなものですブラジル。 ：）

それは（他のすべてのものとして）アプリケーションに依存します。一部のアプリケーション（通常は変更されないか、ルールが実生活の定数に最も適している、つまり物理特性や式など、何年も顕著に変化しない）には、ルールエンジンを使用することは意味がありません。複雑さが増し、開発者はより大きなスキルセットを持つ必要があります。

他のアプリケーションでは、本当に良いアイデアです。たとえば、注文処理（請求書発行から通貨取引の処理に至るまで）は、関連する法律またはコード（司法上の意味）に時々変更され、新しい要件（売上税など）を満たす必要があります。 、クラシック）。 突然、売上税について考える必要があるこの新しい状況に古いアプリケーションを強制しようとするのではなく、以前はそうでなかったように、潜在的に大規模に干渉するよりも、ルールセットを調整する方が簡単ですコードのセット。

次に、地方自治体からの次の修正では、特定の基準内ですべての売上を報告する必要があります。そのため、あなたもそれを追加する必要はありません。最終的には、非常に複雑なコードになります。このコードは、他のすべてに影響を与えずに、ルールの1つを無効にしたいときに、管理が非常に難しいことがわかります...

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

＆quot;しかし、実際には、どのくらいのアプリが本当に多くの変更を行っているのですか？

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

現実には、すべてを前もって考えることはできないため、アジャイルプロセスの理由です。さらに、学士号は常に、テストで見つかるまで重要なものを見逃しているようです。

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

ルールエンジンは、回避可能な場合、カスタムビルドを行う必要がない構成可能なアプリケーションの利点です。また、 Rete のようなルールやアルゴリズムの大規模なベースを一元化するのにも優れています。大きなルールセット。

すでに多くの良い答えがありますが、いくつかのことを追加したかった

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

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

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

Rule Engineでの私の経験の最大の複雑さは次のとおりです：

  1. OOP POVでは、宣言型言語で記述されたルールをリファクタリングおよびテストするときに、それらに影響するコードをリファクタリングするのは非常に苦痛です。
  2. 多くの場合、ルールの実行順序を常に考えて混乱を招くことがあります。
  3. いくつかの小さな変更がルールの不適切な動作を引き起こし、生産上のバグを引き起こす可能性があります。実際には、すべてのケースを前もってテストでカバーできるとは限りません。
  4. 他のオブジェクトで使用されているオブジェクトを変更するルールも複雑さを増し、開発者はそれらを段階的に分割します。
ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top