Droolsを使用する必要があるのはなぜですか？
私はDroolsの専門家ではありません。しかし、私はそれを実験することである程度知っています。私は感謝することができません、なぜそれが必要なのですか？.
私の典型的なアプリケーションはビジネスWebアプリケーションです。はい、ある程度のルールがあります。しかし、これらはデータベーステーブル、SQLクエリ、およびビジネスユーザーがルールを変更するための素敵なUIを使用して実装されます。ルールは恣意的ではなく、本番環境に投入される前に慎重に検討されています。
私のビジネスユーザーは、何かを変更するために（Drools）スクリプト言語を決して使用しません。一人でルールを変更しましょう。彼らは、UI画面を使用してルールを変更することに完全に満足しています。それに加えて、Droolsファイルの近くにどこかにそれらを置くと、膨大な構文エラーを引き起こす可能性があります。
再び
-なぜこのシナリオでDroolsを使用する必要があるのですか？
-Droolsを利用するためにすべてのコードを変更すべきだと私が主張したDrools狂信者がいます。
では、Droolsは役に立ちますか？私はわかりません。
どんな話題についても、熱狂的な話題に関係なく、すべてのストライプの狂信者に質問する必要があります。
データ駆動型の意思決定表は、複雑な動作を実装するのに最適な方法です。当日は、要件に合わせて拡張または実行されないため、おそらく別のことを検討する必要があります。
説得力のある理由がない限り、実際の運用コードでテクノロジーを交換したくありません。それはファンの少年のロビー活動よりもはるかに多くかかります。
本当に興味がある場合は、PoCを実行して実際のデータを取得してください。そうでない場合は、丁寧に笑顔で無視する方法を学びます。
私はこれについて以前に答えました：
更新：それがあなたの上司であり、あなたが却下できない場合は、それをインターフェイスベースにして、PoCでDrools実装を試してください。 Springを使用している場合は、一方を注入し、次にもう一方を注入して、意味のある生産定格負荷の下でパフォーマンスを測定します。実際のデータを取得します-おそらく両方とも何かを学ぶでしょう。
- Droolsはオープンソースです。
- ルール実行の前方および後方チェーンを提供します
- テンプレートの基本ルール定義を提供します
- JSR-94を使用して実装されています
- 決定表機能あり
- そのルールは人間が読める
- Springと統合されています
ルールエンジンの利点は次のとおりです。
- 宣言型プログラミング：ルールにより、困難な問題の解決策を簡単に表現し、解決策を検証することも容易になります。コードとは異なり、ルールはそれほど複雑ではない言語で記述されています。ビジネスアナリストは、一連のルールを簡単に読み取って確認できます。
- ロジックとデータの分離：データはドメインオブジェクトにあり、ビジネスロジックはルールにあります。プロジェクトの種類によっては、このような分離は非常に有利です。
- 速度とスケーラビリティ：Droolsが記述されているRete OOアルゴリズムは、すでに実証済みのアルゴリズムです。Droolsの助けを借りて、アプリケーションは非常にスケーラブルになります。変更要求が頻繁に発生する場合、既存のルールを変更せずに新しいルールを追加できます。
- 知識の集中：ルールを使用して、実行可能な知識のリポジトリ（知識ベース）を作成します。これは、ビジネスポリシーの単一の真実です。理想的には、ルールは非常に読みやすく、ドキュメントとしても機能します。ツールの統合：Eclipseなどのツールは、ルールを編集および管理する方法を提供し、フィードバック、検証、およびコンテンツ支援を即時に取得します。監査およびデバッグツールも使用できます。
- 説明機能：ルールシステムは、ルールエンジンによって行われた決定と、なぜ決定が行われたかをログに記録できるようにすることで、「説明機能」を効果的に提供します。
- 理解できるルール：問題のドメインをモデル化するオブジェクトモデルと、オプションでドメイン固有言語を作成することにより、自然言語に非常に近いルールを作成するように設定できます。彼らは、言語で表現されているため、場合によっては技術者ではないドメインの専門家にも理解可能なロジックに適しています。すべてのプログラムは配管され、技術的なノウハウは通常のコードに隠されています。
ジュエリーの種類に基づいて割引を計算するビジネスロジックを維持する必要があるジュエリーショップの簡単な例を考えてみましょう。これは、Javaコードで実行できます。ただし、このようなルールは毎日変更される可能性があり、コードで定期的に更新する必要があるため、適切ではありません。また、このような変更を行うには常に開発者が必要です。そのため、このロジックをビジネスルール管理システムのルールとして定義することをお勧めします。明日割引が変更することは、これは技術者以外の人でも行うことができます。