ルールエンジンを使用すべきでない場合
ルールエンジンを使用する利点と、それらを使用するいくつかの理由のかなり適切なリストがあります。必要なのは、ルールエンジンを使用しない理由のリストです。
私がこれまでに持っている最高のものはこれです：
ルールエンジンは、実際にはワークフローまたはプロセスの実行を処理するためのものではなく、ルールを実行するように設計されたワークフローエンジンまたはプロセス管理ツールでもありません。
あなたがそれらを使用してはならない他の大きな理由はありますか？
非常に大きなルールセット（たとえば、1つのルールセットで数千のルール）を使用している人を見ると、非常に緊張します。これは、ルールエンジンが企業の中心に位置するシングルトンである場合によく発生します。これは、ルールを維持することで DRY が必要な多くのアプリにアクセスできるようになることを願っています。多くのルールを備えたReteルールエンジンは十分に理解されていると言うために、私は誰にも負けません。競合が存在しないことを確認するためにチェックできるツールは知りません。
ルールを小さく保つためのパーティション化ルールセットは、より良いオプションだと思います。アスペクトは、多くのオブジェクト間で共通のルールセットを共有する方法です。
私は可能な限り、よりシンプルでデータ駆動型のアプローチを好みます。
私はビジネスルールエンジンの大ファンです。なぜなら、それはプログラマとしての生活をずっと楽にするのに役立つからです。データウェアハウスプロジェクトでの最初の経験の1つは、ページ全体に広がる複雑なCASE構造を含むストアドプロシージャを見つけることでした。このような長いCASE構造に適用されるロジックを理解すること、およびコードのページ1のルールとページ5のルールの間に重複があるかどうかを判断することは非常に困難だったため、デバッグするのは悪夢でした。コードに埋め込まれた300以上のそのようなルール。
3000以上のルールの処理を伴うアカウンティング宛先と呼ばれるものの新しい開発要件を受け取ったとき、何かを変更する必要があることを知っていました。当時、私はプロトタイプを作成してきました。このプロトタイプは、後にすべてのSQL標準演算子を処理できるカスタムビジネスルールエンジンの親になります。当初、オーサリングツールとしてExcelを使用していましたが、後で、ユーザーがコードを記述することなくビジネスルールを定義できるASP.netアプリケーションを作成しました。これで、システムは正常に機能し、バグはほとんどなく、このアカウンティング宛先を計算するための7000以上のルールが含まれています。このようなシナリオは、ハードコーディングだけで可能になるとは思いません。また、ユーザーは、ITがボトルネックになることなく、独自のルールを定義できることに非常に満足しています。
それでも、そのようなアプローチには制限があります。
- 会社のビジネスをよく理解している有能なビジネスユーザーが必要です。
- システム全体（この場合はデータウェアハウス）の検索には、ビジネスルールエンジンによって処理されるルールに変換する意味のあるハードコーディングされた条件をすべて決定するために、かなりの作業負荷があります。また、これらの初期テンプレートをビジネスユーザーが完全に理解できるように注意する必要がありました。
- ルールのオーサリングに使用するアプリケーションが必要です。このアプリケーションには、重複するビジネスルールを検出するためのアルゴリズムが実装されています。そうしないと、結果がわからなくなるという大きな混乱が生じます。カスタムビジネスルールエンジンなどの一般的なコンポーネントにバグがある場合、デバッグすることは非常に困難であり、以前は機能していたものが現在も機能することを確認するための広範なテストが必要になります。
このトピックに関する詳細は、私が書いた投稿で見つけることができます： http://dwhbp.com/post/2011/10/30/Implementing-a-Business-Rule-Engine.aspx
全体として、ビジネスルールエンジンを使用する最大の利点は、ユーザーが何かを変更するたびにIT部門に行く必要なく、ビジネスルールの定義とオーサリングの制御を取り戻すことができることです。また、IT開発チームのワークロードが削減され、より付加価値のあるものの構築に集中できるようになりました。
乾杯、
ニコラエ
私が「両刃の剣」であることに気づいたポイツは次のとおりです。
技術スタッフ以外の手にロジックを配置する
技術的な側面以外に1つまたは2つの学際的な天才がいる場合、この作業は素晴らしいものでしたが、肥大化、バグの増加、一般に開発/保守コストの4倍につながる技術の欠如も確認しました。
したがって、ユーザーベースを真剣に検討する必要があります。
Alex Papadimoulisの記事は非常に洞察力に富んでいると思いました。 http://thedailywtf.com/articles/soft_coding.aspx
包括的ではありませんが、いくつかの良い点があります。
ルールエンジンを使用しない場合に関する素晴らしい記事...（およびルールエンジンを使用する場合）...
http://www.jessrules.com/guidelines.shtml
別のオプションは、結果を得るために任意の順序で一度だけ適用されるルールの線形セットがある場合、groovyインターフェイスを作成し、開発者にこれらの新しいルールを作成してデプロイさせることです。利点は、通常は休止状態セッションOR jdbcセッションとパラメーターを渡すため、すべてのアプリデータに効率的にアクセスできるため、非常に高速であることです。ファクトリストを使用すると、システムの速度を実際に低下させる可能性のあるループ/マッチングが大量に発生する可能性があります。データベースと我々は再帰を持っていなかった....それはルールを満たしているか、それをしなかった）。これは単なる別のオプションです.....ああ、もう1つの利点は、開発者向けのルール構文を学習しないことです。彼らはいくつかのグルーヴィーを学ぶ必要がありますが、それはJavaに非常に近いので、学習曲線ははるかに優れています。
それは本当にあなたのコンテキストに依存します。ルールエンジンには場所があり、ルールエンジンを必要としない非常に単純化された状況のために動的にデプロイしたいプロジェクトにルールがある場合、上記は単なる別のオプションです。
基本的に、単純なルールセットがあり、代わりにグルーヴィーなインターフェースを使用できる場合は、ルールエンジンを使用しません....動的にデプロイ可能で、チームに参加する新しい開発者がdrools言語よりも速く学習できるように（しかし、それは私の意見です）
私の経験では、ルールエンジンは次の場合に最もよく機能します。
- 問題のあるドメインに対して明確に定義されたdoctrine
- 入力のほとんどを促進するための高品質（できれば自動化された）データ
- 主題の専門家へのアクセス
- エキスパートシステムの作成経験があるソフトウェア開発者
これらの4つの特性のいずれかが欠落している場合でも、ルールエンジンが機能することがあります。
それは確かに良いスタートです。ルールエンジンのもう1つの点は、一部の事項が十分に理解され、決定論的で、わかりやすいことです。給与の源泉徴収はそのようなものです（または、そうなるように使用します）。 couldルールエンジンによって解決されるルールとして表現しますが、同じルールをかなり単純な値の表として表現できます。
そのため、ワークフローエンジンは、永続的なデータを持つ長期的なプロセスを表現する場合に適しています。ルールエンジンも同様のことができますが、複雑さを追加する必要があります。
ルールエンジンは、複雑な知識ベースがあり、検索が必要な場合に適しています。ルールエンジンは、複雑な問題を解決でき、変化する状況にすばやく適応できますが、基本実装に多くの複雑さを課します。
多くの決定アルゴリズムは、実際のルールエンジンによって暗示される複雑さを伴わずに、単純なテーブル駆動型プログラムとして表現できるほど単純です。
私は次のようないくつかのポイントを本当に理解していません：
a）ビジネスマンはビジネスを非常によく理解する必要があります。
b）ビジネスマンに関する意見の相違は、ルールを知る必要はありません。
私にとって、BREに触れるだけの人として、BREの利点は、システムをビジネスの変化に適応させることと呼ばれるため、変化の適応に焦点を合わせています。
時間xで設定されたルールが時間yで設定されたルールと異なるかどうかは、次の理由で問題になります。
a）ビジネスマンがビジネスを理解していない、または
b）ビジネスマンはルールを理解していませんか？
Drools as open source または Commercial Rules Engine などのLiveRulesなどのビジネスルールエンジンを強くお勧めします。
- 本質的に揮発性のビジネスポリシーが多数ある場合、コアテクノロジーコードのその部分を維持することは非常に困難です。
- ルールエンジンは、フレームワークの柔軟性が高く、変更と展開が簡単です。
- ルールエンジンはどこでも使用する必要はありませんが、定期的に変更が避けられない多くのポリシーがある場合に使用する必要があります。