ルールエンジンを使用する利点のかなりまともなリストと、それらを使用するいくつかの理由があります。必要なのは、ルールエンジンを使用しない理由のリストです。
私がこれまでに持っている最高のものはこれです：
ルールエンジンは、ワークフローやプロセスの実行を処理することを意図したものではなく、ルールを実行するように設計されたワークフローエンジンやプロセス管理ツールでもありません。
あなたがそれらを使用すべきでない他の大きな理由は何ですか？
回答:
非常に大きなルールセット（たとえば、1つのルールセットで数千のルール）を使用している人を見ると、とても緊張します。これは、ルールエンジンが企業の中心に位置するシングルトンであり、ルールをDRYに保つことで、それらを必要とする多くのアプリがルールエンジンにアクセスできるようになる場合によく発生します。私は、多くのルールを持つReteルールエンジンはよく理解されていると誰にでも知らせたいと思います。私は、競合が存在しないことを確認するためにチェックできるツールを知りません。
ルールセットを分割して小さく保つ方が良いオプションだと思います。アスペクトは、多くのオブジェクト間で共通のルールセットを共有する方法となります。
私は可能な限り、よりシンプルで、よりデータ駆動型のアプローチを好みます。
ルールエンジンの使用が悪いアイデアであった個人的な経験から2つの例を挙げます。
レッスン：理由から「ビジネスルール」と呼ばれていますが、ビジネスユーザーが簡単に保守/理解できるシステムを設計できない場合は、ルールを使用しないでください。
レッスン：要件は初期リリースの変更中に大幅に変更される傾向があり、ルールの使用を保証するものではありません。ビジネスが頻繁に変化する場合は（要件ではなく）ルールを使用します。例：-税法が変更され、ルールの使用法が優れたアイデアになると、税を実行するソフトウェアは毎年変更されます。Webアプリのリリース1.0は、ユーザーが新しい要件を特定すると頻繁に変更されますが、時間の経過とともに安定します。コードデプロイの代わりにルールを使用しないでください。
私はビジネスルールエンジンの大ファンです。プログラマーとしての生活をはるかに楽にするのに役立ちます。データウェアハウスプロジェクトでの作業中に最初に経験したことの1つは、ページ全体に広がる複雑なCASE構造を含むストアドプロシージャを見つけることでした。このような長いCASE構造に適用されるロジックを理解し、コードのページ1のルールとページ5のルールとの間に重複があるかどうかを判断するのは非常に困難であったため、デバッグは悪夢でした。全体として、コードに埋め込まれた300以上のそのようなルール。
3000以上のルールを処理することを必要とするAccounting Destinationと呼ばれる新しい開発要件を受け取ったとき、何かを変更する必要があることを知っていました。その当時、私はプロトタイプの開発に取り組んできましたが、このプロトタイプは後に、現在すべてのSQL標準演算子を処理できるカスタムビジネスルールエンジンの親になります。最初はExcelをオーサリングツールとして使用しており、後でASP.netアプリケーションを作成しました。これにより、ビジネスユーザーがコードを記述せずに独自のビジネスルールを定義できるようになります。これで、システムは正常に動作し、バグはほとんどなく、このアカウンティング宛先を計算するための7000以上のルールが含まれています。このようなシナリオは、ハードコーディングだけでは実現できなかったと思います。
それでも、そのようなアプローチには限界があります。
このトピックの詳細は、私が書いた投稿にあります。http：//dwhbp.com/post/2011/10/30/Implementing-a-Business-Rule-Engine.aspx
全体として、ビジネスルールエンジンを使用する最大の利点は、ユーザーが何かを変更する必要があるたびにIT部門に出向かなくても、ビジネスルールの定義とオーサリングを制御できることです。また、IT開発チームの作業負荷を軽減し、より付加価値の高いものの構築に集中できるようになりました。
乾杯、
ニコラエ
私が "両刃の剣"であることに気付いた1つのpoitは、次のとおりです。
論理を非技術スタッフの手に委ねる
非技術的な側面に1つまたは2つの学際的な天才がいるとき、この作品は素晴らしいと思いましたが、肥大化、より多くのバグ、そして一般的に4倍の開発/保守コストにつながる技術の欠如も見ました。
したがって、ユーザーベースを真剣に検討する必要があります。
Alex Papadimoulisの記事はかなり洞察に満ちていると思いました：http ://thedailywtf.com/articles/soft_coding.aspx
それは包括的ではありませんが、彼はいくつかの良い点を持っています。
いつルールエンジンを使用しないかに関する素晴らしい記事...（そしていつ使用するか）....
http://www.jessrules.com/guidelines.shtml
別のオプションは、結果を得るために任意の順序で1回だけ適用される線形ルールセットがある場合は、Groovyインターフェースを作成し、開発者にこれらの新しいルールを作成してデプロイさせることです。利点は、通常、休止状態のセッションまたはjdbcセッションとパラメーターを渡して、すべてのアプリデータに効率的にアクセスできるため、非常に高速であることです。ファクトリストを使用すると、システムの速度を実際に低下させる可能性があるループ/マッチングが多数発生する可能性があります.....これは、ルールエンジンを回避して動的に展開できる別の方法です（そうです、私たちのグルーヴィーなルールはデータベースと私たちは再帰がありませんでした...それはルールを満たしたか、そうでなかったかのどちらかです）。これは単なる別のオプションです.....ああ、もう1つの利点は、新入社員向けのルール構文を学習しないことです。
それは本当にあなたのコンテキストに依存します。ルールエンジンはその場所にあり、ルールエンジンを必要としない非常に簡略化された状況で動的に展開することができるプロジェクトにルールがある場合、上記は単なる別のオプションです。
単純なルールセットがあり、代わりにGroovyインターフェースを使用できる場合は、基本的にルールエンジンを使用しないでください。動的にデプロイ可能で、チームに参加する新しい開発者がdrools言語よりも速く学ぶことができます（ただし、これは私の意見です）。
私の経験では、ルールエンジンは次の条件に当てはまる場合に最もよく機能します。
これらの4つの特性のいずれかが欠落している場合でも、ルールエンジンが機能する場合がありますが、1つでも欠落している状態で試してみるたびに、問題が発生しました。
それは確かに良いスタートです。ルールエンジンのもう1つの点は、一部のことがよく理解され、確定的で、簡単なことです。給与の源泉徴収はそのようなものです（またはそうである必要があります）。あなたは可能性があり、ルールエンジンによって解決されるだろうルールとしてそれを表現していますが、値のかなり単純なテーブルと同じ規則を表現することができます。
したがって、ワークフローエンジンは、永続的なデータを持つ長期的なプロセスを表現する場合に適しています。ルールエンジンでも同様の処理を実行できますが、複雑さを増す必要があります。
ルールエンジンは、知識ベースが複雑で検索が必要な場合に適しています。ルールエンジンは複雑な問題を解決し、状況の変化にすばやく適応できますが、基本的な実装に多くの複雑さを課します。
多くの決定アルゴリズムは、実際のルールエンジンに含まれる複雑さなしに、単純なテーブル駆動型プログラムとして表現できるほど単純です。
Droolsのようなビジネスルールエンジンをオープンソースとして、または商用ルールエンジン（ LiveRulesなど）を強くお勧めします。