111

ルールエンジンを使用する利点のかなりまともなリストと、それらを使用するいくつかの理由があります。必要なのは、ルールエンジンを使用しない理由のリストです。

私がこれまでに持っている最高のものはこれです：

ルールエンジンは、実際にはワークフローまたはプロセスの実行を処理することを目的としておらず、ワークフローエンジンまたはプロセス管理ツールはルールを実行するように設計されていません。

それらを使用すべきでない他の大きな理由はありますか？

4

9 に答える 9

157

ルールエンジンを使用することが悪い考えだった個人的な経験から2つの例を挙げます。おそらくそれは役立つでしょう：-

  1. 過去のプロジェクトで、ルールファイル（プロジェクトはDroolsを使用）にループや関数などを含む多くのJavaコードが含まれていることに気付きました。これらは本質的にルールファイルを装ったJavaファイルでした。建築家に設計の理由を尋ねたところ、「ルールはビジネスユーザーによって維持されることを意図したものではなかった」と言われました。

レッスン：これらは理由から「ビジネスルール」と呼ばれます。ビジネスユーザーが簡単に保守/理解できるシステムを設計できない場合は、ルールを使用しないでください。

  1. 別のケース。要件が十分に定義/理解されておらず、頻繁に変更されたため、プロジェクトではルールを使用しました。開発チームの解決策は、頻繁なコードのデプロイを回避するためにルールを広範囲に使用することでした。

レッスン：要件は、最初のリリースの変更中に大幅に変更される傾向があり、ルールの使用を保証するものではありません。ビジネスが頻繁に変更される場合はルールを使用します（要件ではありません）。例：-税法が変更され、ルールの使用法が優れているため、税金を処理するソフトウェアは毎年変更されます。Webアプリのリリース1.0は、ユーザーが新しい要件を特定すると頻繁に変更されますが、時間の経過とともに安定します。コードデプロイの代わりにルールを使用しないでください。</ p>

于 2009-12-30T22:52:12.553 に答える
37

非常に大きなルールセット（たとえば、1つのルールセットで数千のルール）を使用している人を見ると、非常に緊張します。これは、ルールエンジンが企業の中心にあるシングルトンであり、ルールをDRYに保つことで、ルールを必要とする多くのアプリがルールにアクセスできるようになることを期待している場合によく発生します。その多くのルールを備えたReteルールエンジンはよく理解されていると私に言わないでください。競合が存在しないことを確認するためにチェックできるツールを私は知りません。

ルールセットを分割して小さく保つ方が良いオプションだと思います。アスペクトは、多くのオブジェクト間で共通のルールセットを共有する方法になります。

可能な限り、よりシンプルでデータ駆動型のアプローチを好みます。

于 2009-04-22T00:15:42.283 に答える
20

私が「両刃の剣」であることに気付いた1つのポイントは次のとおりです。

ロジックを非技術スタッフの手に委ねる

非技術的な側面に1つか2つの学際的な天才がいる場合、この作業は素晴らしいと思いますが、技術の欠如が肥大化、バグの増加、一般に開発/保守コストの4倍につながることもわかりました。

したがって、ユーザーベースを真剣に検討する必要があります。

于 2009-04-22T00:00:46.783 に答える
19

私はビジネスルールエンジンの大ファンです。プログラマーとしての生活をはるかに楽にするのに役立つからです。データウェアハウスプロジェクトでの作業中に私が最初に経験したことの1つは、ページ全体に広がる複雑なCASE構造を含むストアドプロシージャを見つけることでした。このような長いCASE構造に適用されるロジックを理解し、コードの1ページのルールと5ページのルールが重複しているかどうかを判断するのは非常に困難であったため、デバッグするのは悪夢でした。コードに埋め込まれた300以上のそのようなルール。

3000を超えるルールの処理を伴う、アカウンティングデスティネーションと呼ばれる新しい開発要件を受け取ったとき、私は何かを変更する必要があることを知っていました。当時、私はプロトタイプに取り組んできました。このプロトタイプは、後ですべてのSQL標準演算子を処理できるカスタムビジネスルールエンジンの親になります。最初はExcelをオーサリングツールとして使用していましたが、後で、コードを記述せずにビジネスユーザーが独自のビジネスルールを定義できるASP.netアプリケーションを作成しました。これで、システムは正常に動作し、バグはほとんどなく、このアカウンティング宛先を計算するための7000を超えるルールが含まれています。このようなシナリオは、ハードコーディングするだけでは不可能だったと思います。

それでも、そのようなアプローチには限界があります。

  • あなたは会社のビジネスをよく理解している有能なビジネスユーザーを持っている必要があります。
  • ビジネスルールエンジンによって処理されるルールに変換するのに意味のあるすべてのハードコードされた条件を決定するために、システム全体（この場合はデータウェアハウス）の検索にはかなりの作業負荷がかかります。また、これらの初期テンプレートがビジネスユーザーに完全に理解されるように注意する必要がありました。
  • ルールのオーサリングに使用するアプリケーションが必要です。このアプリケーションには、重複するビジネスルールを検出するためのアルゴリズムが実装されています。そうしないと、大きな混乱に陥り、得られる結果を誰も理解できなくなります。カスタムビジネスルールエンジンなどの汎用コンポーネントにバグがある場合、デバッグが非常に困難になる可能性があり、以前は機能していたものが現在も機能することを確認するための広範なテストが必要になります。

このトピックの詳細については、私が書いた投稿を参照してください：http: //dwhbp.com/post/2011/10/30/Implementing-a-Business-Rule-Engine.aspx

全体として、ビジネスルールエンジンを使用する最大の利点は、ユーザーが何かを変更する必要があるたびにIT部門に行く必要なしに、ビジネスルールの定義とオーサリングの制御を取り戻すことができることです。また、IT開発チームの作業負荷が軽減され、より付加価値の高いものの構築に集中できるようになります。

乾杯、

ニコラエ

于 2012-01-22T08:58:33.690 に答える
11

ルールエンジンを使用しない場合（および使用する場合）に関するすばらしい記事...

http://www.jessrules.com/guidelines.shtml

もう1つのオプションは、結果を得るために任意の順序で1回だけ適用される線形のルールのセットがある場合、Groovyインターフェースを作成し、開発者にこれらの新しいルールを作成してデプロイさせることです。利点は、通常は休止状態セッションまたはjdbcセッションと任意のパラメーターを渡すため、すべてのアプリデータに効率的にアクセスできるため、非常に高速であるということです。ファクトリストを使用すると、システムの速度を実際に低下させる可能性のあるループ/マッチングが多数存在する可能性があります.....これは、ルールエンジンを回避し、動的にデプロイできるようにする別の方法です（はい、Groovyルールはデータベースと再帰はありませんでした....ルールを満たしているか、満たしていないかのどちらかです）。これは単なる別のオプションです.....ああ、もう1つの利点は、次期開発者向けのルール構文を学習しないことです。

それは本当にあなたの文脈に依存します。ルールエンジンにはその場所があり、ルールエンジンを必要としない非常に単純化された状況で動的にデプロイしたいプロジェクトにルールがある場合、上記は単なる別のオプションです。

基本的に、単純なルールセットがあり、代わりにGroovyインターフェイスを使用できる場合は、ルールエンジンを使用しないでください。動的に展開可能で、チームに参加する新しい開発者が、drools言語よりも速く学習できるのと同じです。（しかし、それは私の意見です）

于 2011-11-04T17:50:55.147 に答える
8

私の経験では、ルールエンジンは、次のことが当てはまる場合に最適に機能します。

  1. 問題のドメインに対して明確に定義された教義
  2. ほとんどの入力を促進するのに役立つ高品質（できれば自動化された）データ
  3. 対象分野の専門家へのアクセス
  4. エキスパートシステムの作成経験を持つソフトウェア開発者

これらの4つの特性のいずれかが欠落している場合でも、ルールエンジンが機能することがわかるかもしれませんが、1つでも欠落している状態で試してみるたびに、問題が発生します。

于 2009-09-30T15:37:56.803 に答える
1

それは確かに良いスタートです。ルールエンジンのもう1つの点は、よく理解され、決定論的で、単純なものがあることです。給与源泉徴収はそのようなものです（または以前はそうだった）。ルールエンジンによって解決されるルールとして表現することもできますが、同じルールをかなり単純な値のテーブルとして表現することもでき ます。

したがって、ワークフローエンジンは、永続的なデータを持つ長期的なプロセスを表現する場合に適しています。ルールエンジンも同様のことを行うことができますが、さらに複雑にする必要があります。

ルールエンジンは、複雑な知識ベースがあり、検索が必要な場合に適しています。ルールエンジンは複雑な問題を解決でき、状況の変化にすばやく適応できますが、基本的な実装に多くの複雑さを課します。

多くの決定アルゴリズムは、実際のルールエンジンによって暗示される複雑さなしに、単純なテーブル駆動型プログラムとして表現するのに十分単純です。

于 2009-04-21T23:57:01.893 に答える
0

Droolsのようなビジネスルールエンジンをオープンソースとして、またはCommercialRulesEngineのようなLiveRulesを強くお勧めします。

  • 本質的に不安定なビジネスポリシーがたくさんある場合、コアテクノロジーコードのその部分を維持することは非常に困難です。
  • ルールエンジンは、フレームワークの優れた柔軟性を提供し、変更と展開が簡単です。
  • ルールエンジンはどこでも使用できるわけではありませんが、定期的に変更が避けられないポリシーがたくさんある場合に使用する必要があります。
于 2013-04-30T13:43:54.553 に答える
0

私は次のようないくつかの点を本当に理解していません：
a）ビジネスマンはビジネスを非常によく理解する必要がある、または;
b）ビジネスマンの意見の不一致はルールを知る必要はありません。

私にとって、BREに触れるだけの人として、BREの利点は、システムをビジネスの変化に適応させることと呼ばれているため、変化の適応に焦点を当てています。
次の理由により、時間xに設定されたルールが時間yに設定されたルールと異なるかどうかは重要ですか。a
）ビジネスマンがビジネスを理解していない。
b）ビジネスマンはルールを理解していませんか？

于 2013-05-21T14:04:23.753 に答える