Gleyzer両氏によって共同開発されました。2019で、同言語の発表を行いました。InfoQはPurdy氏に言語と、氏らが解決を目指した問題について聞きました。設計/アーキテクチャアジャイルマニュフェスト:ソフトウェアアーキテクトの視点ソフトウェアアーキテクトの役割と責任はアジャイルソフトウェア開発のためのマニフェストの価値と矛盾していると見えますが、優れたアーキテクトはアジャイル開発チームをサポートするテクニックを見つけています。Streamingは、ストリーミングデータのためのSQLライクなインターフェースを提供します。Streamsによって、Redisがストリーミングデータを複数のプロデューサとコンシューマの間で消費、保持、配信することができるようになります。ソフトウェア開発のマニフェストたゆまず息もつかずに市場に突進することで、会社を静かに消滅の崖っぷちへと追い込みます。それは設計してコードを書く方法を再考する時です。簡単さへの投資は、速さへの投資です。簡単さは知的財産の主鉱脈でもあります。競争上の優位性は、一度失ったら、もう一度手に入れることはほとんど不可能です。Buytaerts氏が過去10年間にわたって、企業がDevOps採用のハイプサイクルをくぐり抜け、変革に対する誤解を解消する過程を支援してきた経験について語ります。多くの開発者にとって、ルールエンジンと言うのは単なるバズワード、もしくはアーキテクチャの図上のブラックボックスです。遠くの方から恐れられたり、称賛されたりしていますが、理解されてはいません。ルールエンジンのような新しいパラダイムを受け入れる際には、技術のどうしようもないジレンマが存在します。現実世界で直に接してみるまでは、技術をいつ使用するのか、どうやったらそれをうまく適用できるのかを知るのが難しい実際に体験してみるための最も一般的な方法は、実際のプロジェクトで知らないテクノロジーを使用してみることだ本番環境で、新しい技術を使用した経験を実際に得ることは、将来の仕事においてかけがえのない経験である。大きなリスクを背負うことになるこの記事では、私が金融サービス向けの市場ソリューションをサポートするためにルールエンジンとDroolsを実践した経験を共有し、ルールエンジンの便利な個所と、あなたが直面している問題に対してどのようにルールエンジンを適用するのが最良か、を理解する手助けとなることを目指しています。注意を払うべきか?読者の中には、ルールエンジンの使用を既に考えていて、それをうまく使うための実践的なアドバイスを探している方もいらっしゃるでしょう。パターンとアンチパターン、ベストプラクティスと落とし穴、などです。関連スポンサーコンテンツその他の方々はルールエンジンの使用を考えていない、あなたが従事している仕事にどう適用できるのかよくわからない、もしくはルールエンジンの使用を考えたがそのアイデアを捨ててしまった、というところでしょう。ルールエンジンはビジネスロジックを外部化するためのパワフルな方法で、ビジネスユーザに力を与え、非常に多くの細かいビジネスルールとファクトが相互作用する中で、複雑な問題を解決することができます。あなたが条件分岐を多用していて、その組み合わせを評価しようと試み、一つの問題を片づけるため深く入れ子になったロジックを書いていることに気づいたなら、これらは単に一種のもつれ合いであり、ルールエンジンがそれを解く助けになります。いくつかのより複雑な金融サービスは、ルールアプローチで表現し直してみると、より理解しやすくなりました。手続き型の条件分岐ロジックを、Droolsのビジネスルールに変換する各ステップが、より多くの単純さと、より多くのパワーを顕在化させていくようでした。最後に、もしあなたが上記のことを信じられないなら、このように考えてください。ルールエンジンはツールであり、ソフトウェア開発アプローチの異なる方法だと。ツールは強みと弱みを持っており、もしあなたがルールエンジンをすぐに活用することができなくとも、そのトレードオフを理解する役には立ち、将来その適用可能性を評価し、伝えることができるのです。ルールエンジンの基礎いつ、どうやってルールエンジンを使うのかをお話しする前に、ルールエンジンとは何かを説明するのは意義があります。ルールエンジンとは何か?ルールエンジンとは、その中核は、'ビジネスルール'を実行するためのメカニズムです。ビジネスルールは、ビジネスにおけるある種の決定を表した、単純なビジネス指向のステートメントです。多くの場合は、非常に単純なif/thenの条件分岐で表されます。結果、保険料は20%の割増です。これらのビジネスルールは新しいものではありません。多くのビジネスソフトアプリケーションの中核となるビジネスロジックです。あなたが開発者なら、こうしたルールは要件のサブセットとして表現されているのを何度となく見たことでしょう。これらは、"月曜日は、3つ以上のご注文で20%のディスカウント"や"スーパースポーツ・バイクでは、16才の男性に保険を掛けることはできません"といった文章に似ています。ルールエンジン間の主な違いは、こうしたルールがどう表現されるか、です。プログラムの中に埋め込まれる代わりに、これらはビジネスルールの書式に符号化されます。この書式はルールエンジンごとに違っています。ルールエンジンは、何の制限も受けていません。ルールを管理するための、他のツールと一緒にリリースされることがよくあります。一般的なオプションとしては、生成、デプロイ、保存、バージョニング、そして個別もしくはグループでのルール管理などです。ルールエンジンの一つの例は、最近JBossグループの傘下に入ったDroolsです。Droolsはフリーで利用でき、オープンソースで、良いコミュニティを持っています。そのため、ルールエンジンを最初に検討するには優れた選択肢ですし、この記事でも例として使用されます。他のルールエンジンについてさらに情報を得たい方は、サイドバーのその他のルールエンジンを見てください。ルールエンジンはどのように動作するのか?ルールエンジンの根本的な性質は、それを動作させるアルゴリズムから来ています。いくつかの単純な'ルールエンジン'は、手続き型のロジックをあなたが指定した順番で単に次々と実行するだけです。ほとんどのルールエンジンは、ファクトとルールを繋ぐために、ReteやTreat、Leapsといった洗練されたマッチングアルゴリズムを提供しており、どのルールがどの順番で実行されるべきかを決定します。Reteの詳細を取り扱うのはこの記事の範疇から外れていますが、単純に言うとこうです。Reteは状態マシンのように、ルールからツリーを構築します。ファクトはルールへのパラメータとしてツリーのトップレベルノードへと入り、条件に合致するとツリーを降りていきます。ツリーの葉、つまりルールの結果に到達するまでそれは繰り返されます。Reteの作者や他の開発者達はReteの成功を受けて、新しいアルゴリズムにより改善を試みました。IIIであり、そのいくつかは他のルールエンジンにより使われています。これらのマッチングアルゴリズムは、コードの切れ端を単純に、順番通りに実行するよりも複雑です。全てのファクトに対し全てのルールを順番に実行したいとしたら、ルールエンジンは遅いでしょう。ルールエンジンのアプローチには、それを使用しない時には存在しないオーバーヘッドが存在します。マッチングルールがデータに対して行う作業が自明でない場合には、ルールエンジンが洗練されていれば、条件の共有などのメカニズムにより時間を短縮できます。条件の共有とは、複数のルール間で条件を共有することで、条件の評価がルールごとに毎回行われるのではなく、最初の一度だけで済むというものです。あなたがもし教育スケジュールのシステムを作っているとして、生徒のクラス分けを行うとします。それが生徒たちの望みを最大限尊重しながら、生徒の組み合わせを可能な限り記録するというものだとすると、ルールエンジンは恐らく非常に遅いです。似たような人口統計データに対して、クエリの組み合わせを繰り返し行う必要のある保険システムでは、協調動作を行うためのカスタムコードを一切必要とすることなく、条件の共有とパターンマッチングがソリューション全体の複雑さを劇的に減らします。ルールはどのように書くのか?これは、ルールエンジン毎の差異が大きい分野です。複数の既存の言語をフルに、もしくは断片的にサポートしているものもあれば、プロプライエタリな言語を提供しているもの、ビジュアルな設計システムを提供しているものもあります。一部のエンジンは、ルールの作成や管理、ルールの開発環境を含めて広範囲にわたりツールサポートを行っています。その他のものはIDEからテキストエディタ、スプレッドシートなど、既存のツールとの統合に力を入れています。5.0アノテーションで紐付けるといった方法を提供しています。3.0では、XMLのラッパーを必要としない独自のルール言語を持ちます。この言語は新しいユーザにとってもより読みやすいので、私もこのシンタックスを使用します。3.0のDRLでは以下のようになります。3.0ではドメイン固有言語拡張と自動補完機能を含んだEclipseプラグインを持ち、ルールの作成やデバッグもサポートします。このように、これからはDroolsユーザ向けのツールサポートも増えていくことでしょう。ルールエンジンは何に向いているか?ルールエンジンには様々なものがあります。それぞれに固有の強みを持っており、あるルールエンジンを使うことで得られる利益が、あらゆるエンジンで同じように得られるわけではありません。ほとんどのルールエンジンに当てはまる一般的な性質もいくつか存在します。「より良い」、もしくは「より悪い」と言ったものではなく、単に異なっているのです。基本的には、汎用目的のプログラミング言語とルールエンジンは同じ類の問題を解決するために使われうるものです。ルールエンジンを使用してより簡単に解決できる問題もあれば、汎用目的のプログラミング言語が適している問題もあります。ルールエンジンは、「どのルールがどういった順番で実行されるか」を決定するためのマッチングアルゴリズムを提供します。ルールの記述者は、必要に応じてフィルタやワークフロー、衝突解決などの制御を行うこともできます。ルールエンジンを使うと、事象をルールによって捉えなおすことができます。あるルールの結果がファクトベースに影響を与えることを許したり、必要に応じて他のルールを実行したりキャンセルしたり、といった具合です。ルールエンジンのこうした性質により、ファクトとルールは単純でもパワフルな結果が得られるといった、巧妙な相互作用を作り出します。した特質は、しばしば汎用目的のプログラミング言語を超える価値を提供します。最後に、イントロダクションで我々が論じたように、あるパターンを実践するためにルールエンジンを使用する人もいます。ビジネスロジックの外部化、迅速な変更のサポート、ビジネスユーザの力になること、などです。したアプローチは、以降の文章でさらに詳しく論じます。ルールエンジンは何に向いていないか?あらゆる問題に対してルールエンジンを適用することも、頑張れば不可能ではないでしょうが、ルールエンジンは単に道具箱の中の道具の一つでしかありません。ルールエンジンは制約に基づくプログラミングや解法、人工知能、ワークフローエンジン、デシジョンテーブル、汎用目的のプログラミング言語を置き換えるものではありません。他のツールを補うものでしかありません。車両保険の見積もりルールエンジンを使用したアプリケーションは、ルールエンジン自身によって変わってきます。特定の例を挙げることを考えると、それはしばしば便利です。車両保険の見積もりを行うシステムを想像してください。している保険、車などの正確な情報や、顧客自身が受け取る見積もり自体をいくつも審査する必要があります。その後、システムは保険の見積りを用意してユーザに表示し、受諾されたり、受諾されなかったり、もしくは後日まで引き延ばされたりします。したシステムの大部分は、汎用目的のプログラミング言語で比較的素直に開発できますが、顧客の情報から見積もりの準備を行うプロセスに関しては複雑です。多くのデータ変更、ビジネスルールの変更、規制の変更などを扱うため、通常の開発プロセスでは困難です。多くの場合、これはルールエンジンの方が優れている環境の類で、見積もりを準備するプロセスをルールエンジンに任せることが可能です。ルールエンジンを用いたアーキテクチャを構築する新規もしくは既存のシステムにおけるアーキテクチャと、ルールエンジンを統合するための最適な方法は、個々のルールエンジンが持つ仕様によって大きく異なります。サーバ型と埋め込み型いくつかのルールエンジンはサーバを必要、もしくはあった方が良く、リモートからの呼び出しを行うことができます。これらは、EJBやCORBA、SOAと言った分散コンピューティングを使用した環境とうまく適合します。その他の物は完全に組み込み型で、ドメインオブジェクトとともに直接動作し、それらを直接変更します。このアプローチは、ルールと周辺ソフトウェアの間に信頼性の境界が必要ない場合にうまく適合します。なければ汚染を防ぐレイヤが必要になるでしょう。ルールのパフォーマンス分散コンピューティングを使っていない場合は概して、組み込み型ルールエンジンの方がパフォーマンスが良好です。サーバ指向のルールエンジンはサービス指向の環境内でうまく動作し、ルールエンジン自身がスケーラビリティを提供します。ルールエンジンは、ビジネスルールを選択して協調動作させるための一般的な方法であり、完全なカスタムソリューションのような速度を提供するものではありません。うまく構築されたルールソリューションは、アプリケーション全体に対して大きなパフォーマンスの劣化をもたらすものではありません。ルールソリューションのパフォーマンスは、ルールを起動するエンジンよりも、ルール自体の構成とコードに依存しがちです。個々のルールエンジンは、パフォーマンスの観点から見たベストプラクティスをそれぞれ持っているものです。全般に対して共通なものではないため、これらへの依存関係を可能な限り薄くしておくことが重要です。Droolsでは、スケジューリング処理の最初の方では条件が繰り返し実行されます。そのため、処理が高価かつ頻繁に評価されるような条件があると、パフォーマンス全体にかなりの影響を及ぼします。使用しているルールエンジン上でルールソリューションの開発に慣れるまでは、パフォーマンスに対して常に注意を払っておくべきでしょう。ルールの管理ルールそれ自体は、中央リポジトリで管理されユニークなIDを通して参照されるか、ファイルシステムやデータベースから直接ロードされます。ファイルシステムからルールを読み込む場合は、ルールをコードの一部としてソース管理システム内で管理したり、外部のツールセットなしでルールを変更する、と言ったことを簡単に実現できます。リポジトリによるルール管理では、ルールの作成/管理/デプロイを行うツールのおかげで、ソース管理システムやビルドスクリプトを理解したり、ローカルでファイルのバージョンを管理する必要がありません。そのため、開発者ではない人間がルールの作成に参加するのを容易にします。Droolsは組み込み型で、ドメインオブジェクトと直接やり取りします。ルールは様々な方法でロードできますが、ファイルシステムアプローチが最も一般的です。サンプルアーキテクチャ車両保険の見積もりを作成するためのルールエンジンソリューションのアーキテクチャは、最終的に以下のような感じになるでしょう。見積もりルールをWARの外側に置いておくことで、サーバを使用しているアプリケーションとは別のライフサイクル上で、それらをデプロイ、再デプロイすることが可能になります。ルールを軽量に保ち、実装から切り離しておくことで、ルールが必要とするあらゆる情報をルール内で直接読み込むのではなく、外から渡すようにします。典型的な場合ルールは、実行するルールの'集合'を抽出してから呼び出され、ルールエンジン内で一連のファクトをアサートします。これらファクトは、実行される条件と結果のうち、どれがどのルールパラメータに紐付き、依存するかを表すオブジェクトです。一つ以上のアサーションが一度でも作成されると、ルールエンジンが呼び出されます。ルールの'集合'が選択されると、ルールエンジンはどのオブジェクトに対してどのルールをどんな順番で実行するかを選択します。ルールは、既存のオブジェクト集合を直接変更します。その変更によって集合の一部を削除したり、新しいオブジェクトを追加したりすることもあります。Commandデザインパターンと少し似ています。ルールが実行するオブジェクトやルールの結果について知る必要がないよう設計されていることです。あるルール集合を使用するためには、呼び出し元は必要とされるインプットを理解しておかねばならず、その暗黙的な作用についても少しは理解している必要があるかもしれません。ルールエンジンがDroolsの場合、見積もりの作成は以下のようなシーケンスになるでしょう。WorkingMemoryオブジェクトとして表現されているステートフルなコンテキストへと取り出されます。現在の状態はワーキングメモリー内でアサートされ、ルールが起動され、何らかの見積もり結果が戻されます。ルールエンジンをサービスファサードの裏側に置くことで、「見積もりの作成のためにルールエンジンを採用した」という実装の詳細がカプセル化されます。ユーザインターフェースやサービス、データアクセスといった既存の部分は変更する必要がありません。間で関心事の分離を行っています。これまでとは異なる新しい市場へも簡単に投入できるかもしれません。単一の見積もりを算出するサービスでも、ルールの一部を、別の地域や保険業者などに任せることができます。ここに示した単純な例は、ルールエンジンが保険業界のコンテキスト内でどのように使われうるかを示したものです。他にもルールエンジンが適用できる場面は数多くあります。あなたのアプリケーションにルールエンジンを統合する方法は他にもたくさんあります。重要なのは、この実際に動作する例を用いて、ルールエンジンの使用におけるパターンとアンチパターンに関したさらなる議論を行うことができると言うことです。ルールエンジンのパターンとアンチパターンルールエンジンを適用するために、取り得る方法は数多くあります。した方法はそれぞれトレードオフを持ち、あなた自身がルールエンジンを使用する際役に立つ情報をいくつか与えてくれます。ほとんどの場合、あなた自身の環境でこれらのトレードオフを検証する最も優れた方法は、ルールエンジンを実際に使ってみることです。ビジネスロジックの外部化アプリケーション自身からビジネスルールを外部化する手段として、多くのビジネスがルールエンジンを選択しています。これにより、アプリケーション自身とは異なるライフサイクルでルールが開発/テスト/デプロイされることを可能にします。これはしばしば、より深いビジネスのニーズをサポートします。迅速な変更や、次のビジネスを導出することなどです。ルールエンジンを使うと、アプリケーションの核となるビジネスルールをアプリケーションのリコンパイルや再配備なしに変更でき、関心事の分離を確立します。異なるライフサイクル上で開発を行うことができます。ルールエンジンは、ビジネスルールを外部化するための実現可能な手段ではありますが、それがもたらす便益はまだ探究の余地があります。他の方法でも同じような利益を得ることは可能ですし、このアプローチがもたらす便益を他のアプローチと比較して測ることが重要だということです。あなたの関心事が、アプリケーションから切り離した形でビジネスルールのデプロイを行うというだけであれば、これを達成するためだけにルールエンジンを使用するのは、もっとも簡単な方法だとは言えません。実行時にロードしたりリロードしたりすることができます。あなたの関心事が、明示的なリコンパイルのサイクルを避けることにあるのだとすれば、スクリプト言語の使用や、Janinoなどの動的リコンパイル技術を考慮してみてください。した選択肢の多くは、ルールエンジンと比べると時間やエネルギー、ライセンスコストの節約になります。ルールエンジンは、その他の領域でも多くの利点を提供しています。変更の迅速性ビジネスルールは、環境によっては頻繁に、絶え間なく変わります。あるチームは、ルールエンジンを使ってこうした種類の変更をサポートしようとしています。前の節で述べたように、アプリケーションコードからビジネスルールを外部化し、これらのルールを別に変更し、デプロイ、またはホットデプロイさせることができます。加えていくつかのルールエンジンは、ビジュアルな設計や動的言語をサポートしており、迅速な開発アプローチをサポートしています。保険の規制や新しい統計は、短い期間で適用されなければならない変更を引き起こし得ます。従って、ルールの生成を行うロジックが、この種の変更を素早く行うことをサポートしているかどうかを知っておくことは重要です。結局、ルールエンジンは変更をサポートする魔法の弾丸ではなく、助けになるものです。ルールエンジンを使おうと使うまいと、これらと同様のアプローチの多くを得ることはできますが、こうしたアプローチを自分で実装するのは、ルールエンジンに付属するツールを使用するほどにコスト効果が良くありません。ビジネスロジックの外部化と同様、変更の迅速性だけがあなたの関心事ならば、ラピッドデベロップメントツールやスクリプト言語を考慮するとよいでしょう。これらは作業、時間、金の投資がルールエンジンよりも少なくて済みます。(そういう環境なら特に)、テストが最も重要な関心事である、と言うことを強調しておくのは重要です。テストなしに、動作中のアプリケーション内で複雑なビジネスルールを変更するのは、災害を引き起こすためのレシピのようなものです。ビジネスユーザがビジネスルールを開発するビジネスルールは通常、ビジネスに携わっている人によって定義されます。ほとんどのビジネスでは、それらは開発者によって実装されています。ルールを開発できるよう、ルールエンジンを変えようとしています。それが成功した暁には、ビジネスユーザ自身がビジネスソリューションのコントロールを行い、システムに継続的に関与し、システムに何ができて何ができないかを理解し、根本的に新しい機能をユーザが求めたときのみ開発者に問い合わせる、と言ったことを促進するでしょうこうした事柄をルールエンジンが改善する、と言うのはしばしば正しいのですが、並の複雑さを持つルールソリューションでさえも、そのほとんどが開発者の関与を必要とする、と言うのもまた真です。ツールサポートが極めて使いやすくなったとしても、境界値のケースや極端な条件式など、多くのビジネスユーザにとって開発する必要がない、技術的な分析の考え方や困難が存在します。した場合において最も成功するソリューションは、開発者とビジネスユーザの間の協力関係を促進することです。開発者が境界を引き、大まかな構成については準備し、必要とされる技術的な複雑さを取り扱います。ビジネスユーザは、よりコントロールされた環境下で、個々のビジネスルールの仕様をカスタマイズすることができるのです。車両保険の仲介業者にとっては、以下のような目的のために、開発者を雇用すると良いでしょう。前もって作成するためです。我々が携わった、さらに最近のプロジェクトのうちのいくつかで、Droolsの"デシジョンテーブル"を使って非常に効果を上げることができました。ビジネス上の決定をルールに任せた形のビジネスドメインとアプリケーションを、Java開発者が作成、拡張しました。一連のデシジョンテーブルの構造を作成するために、ソリューションの境界で区切った形式の、複数のExcelワークブックを使用しました。するとビジネスを分析する側のチームメンバーは、ビジネスのゴールを満たすためにこれらのテーブルをパラメータ化することでルールを作成することができました。125%これはかなり成功しました。この仕事ではいくつかのイテレーションを経て、開発者のサポートを受けながらも、ビジネスユーザはさらに多くの責任を負ってデシジョンテーブルの構造を作成しようとしています。した習慣を実現するためにルールエンジンを検討する場合は、都合のよいビジネスユーザを見分けることが重要です。ビジネスルールを作成/修正したいと望んでおり、それらを試し、できればビジネスユーザにとって都合のよいシナリオだけではなく、いくつかの現実的なシナリオを開発するためにツールを使用してくれるようなビジネスユーザです。ビジネスユーザが使いたがらないツールに対して全力を傾ける前に、製品に対していくつかの検討を行うための、適度に長い評価期間を考慮してください。フロー制御の放棄いつ、どのルールを実行するかをルールエンジンの決定に任せることは、ルールエンジンのフルパワーを引き出すために重要なステップです。ビジネスロジックの実行を制御することに慣れた開発者たちにとっては、この移行は厄介なものに思えます。一度こうした方法に慣れて来ると、かなりのパワーを提供してくれるものだということがきっとわかるでしょう。多くのルールエンジンは、実行に影響を及ぼすルールの選択と順番づけを行います。Droolsは、コンフリクトを解決するストラテジや、それらを制御するためのsalienceやagenda-groupと言ったルールの属性を数多く提供しています。した種類のオプションにより、フロー制御の全体をルールへと分離することができます。ビジネスロジックの要件を完全に満たすため、もしくはルールエンジンが採用しているアプローチを調整するために、必要なコントロールは何でも使うよう努力しなくてはなりません。手続き型のコードとしてのルールもしあなたが手続き型のプログラミングをかなり多く行ってきたのであれば、ルール指向の開発モデルに切り替えることは少しハードルが高いかもしれません。あなたは慣れ親しんできた手続き型の開発パターンにすぐさま陥り、以下のような質問をするでしょう。一つのルールだけを実行するにはどうしたらいいのか?実行したいルールを順番どおりにリストできるか?重要なのは、こうしたことを行うこととは可能ですが、常に望ましいわけではないということです。Droolsでは、アクティベーションフィルタを使用すればどのルールが実行されるかを制御することができますし、コンフリクト解決を使用すれば順番を制御することもできます。した方法をとるのは我慢してください。これらが必要な場合もありますが、これらを使うとあまりにも簡単に、古い手続き型のパラダイムに陥ってしまいます。クロス乗積ルールエンジンに与えるファクトを組み立てる際には、発生する組み合わせや、少数のファクトとルールの組み合わせでも、結果としてその組み合わせ数がすぐに驚くほど膨大になってしまうと言うことをすぐに忘れてしまいます。2つの車種と一人の顧客を参照する保険のルールがあるとします。ナレッジベースが5,000の車種と5,000人の顧客から構成されていたなら、エンジンは2,500万もの車種の組み合わせを5,000人の顧客それぞれに考慮しなければならず、トータルの組み合わせは1,250億にもなります。ルールエンジンに比較させるものの規模を考慮し忘れると、あなたはこうしたルールを書いてしまい、ソリューションが期待したようなパフォーマンスを発揮しないのを目の当たりにすることになるでしょう。従ってルールソリューションの開発を行う際には、規模に対するセンスを持つことが重要です。これは、ルールに渡し、導出される情報の量を制限したり、定期的なパフォーマンステストと負荷テストを確立し、継続的にメトリックスを評価することによって実現することが可能です。一つのルールが、特定のタイプのファクトを一つ以上とるとき、ルールエンジンはこれらのファクトに対する全ての順列と組み合わせを提供しようとします。した振舞いを必要とするファクトもありますが、その他の場合では、一意となる組み合わせや重複のない組み合わせが望まれることでしょう。これは通常、ルールの条件によって行うことができます。ルールにおいて項目の重複を避けるには、一つ目の項目が二つ目と同一でない、と言う条件をつけ加えてください。一意となる組み合わせを得るには、オブジェクトの順序付けを使用することができます。Javaではオブジェクトのハッシュコードを用いて、こうしたことを実現できます。いくつかのルールエンジンは、組み合わせと順列の数を減らすためのこうした機能を持っています。従って、あなたが使用するルールエンジンが持つこうした機能や、どのような組み合わせが生成されるのかを理解することは重要です。2はこうした組み合わせの全てを提供しています。フィルタによって重複した項目を除去します。再帰ソフトウェアにおけるフロー制御のいかなる形式でも、自身の再帰呼び出しは問題となります。ルールがファクトベースを変更してしまい、その変更によって同じルールが再度呼び出されるとすると、結果は無限ループでしょうか?もしくは、あるルールが他のルールを呼び出し、最終的に最初のルールを再度呼び出すような、ルールのサイクルを作ってしまうこともあります。した種類のサイクルは、ルールを設計する際に防いでおかないと、十分あり得ることです。いくつかのケースでは、注目に値するほど単純ですが、ルールを定義するときに、決して自分自身を呼び出さないようにするというものです。loop'属性を持っています。した方法を用いて、自身を呼び出さないようルールを設計する、と言うのが多くの場合最良の解決策です。保険見積りに割引を適用するルールを使用していたとして、見積もりに指定された割引を行わない、と言うルールの条件を単純に作成します。これは、割引のルールが自信を呼び出さないと言うことを意味するだけではなく、一般的なケースを最も優先度が低いものとする、割引ルールの階層構造を構築することができ、それらは奇麗に相互作用します。した類の設計上の決定は、ルールエンジンに対するルールの開発に十分時間をかけると、自然に行えるようになります。あなたが手続き型やオブジェクト指向のコードを書いてきたという経験があるなら、すぐにはっきり理解できるわけではありません。粒度ルールエンジンを初めて使うときには、典型的なプログラミングパラダイムに則って、ルールやそれを動かすデータの粒度を扱いたくなるものです。巨大で複雑なルールを書き、フロー制御をルールエンジンではなくルールに行わせるきめの細かいファクトを使い、それらの中から適切なファクトを抽出することをルールエンジンに行わせるのではなく、巨大なオブジェクトグラフをルールエンジンに与え、ルール内でオブジェクトグラフを操作するこうしたアプローチにより、既存のアプリケーション内にルールエンジンを素早く統合し、新しいテクノロジーによってもたらされるリスクが露見するのをコントロールできます。したアプローチは、ルールソリューションが持つパワーを制限することにもなってしまいます。ルールエンジンの実装がもたらす新たな価値を享受するには、ルールエンジンにより自由を与えるのが最良の方法です。小さくてきめが細かく、単純なルールを作成する小さくてきめが細かく、単純なファクトからルールを作成するこうしたルールは、有効/無効をより簡単に切り替えることができます。簡単に組み合わせることができます。コンフリクトの解決により、ルールエンジン内で順序替えを行うことができます。開発者以外にも簡単に書くことができます。それらがルールの集合として一斉に適用されると、その結果は驚くほど複雑なものとなります。DroolsのJava/XMLルールを使った以下のような例を考えてみてください。elseこのケースでは、通常は一つ以上のルールで構成するのが適切な、条件分岐のロジックを含んでいます。同様に、PolicyからDriverを取り出すと言うドメインオブジェクトのナビゲーションに頼っているため、Policyを必要とせず、Driverだけを必要とするようなルールを記述するのが難しくなっています。このルールは、以下のような形式の、いくつかのルールに書きなおすことができます。endこうしたルールはよりシンプルで、書くのも理解するのも容易で、疎結合のマナーに従ってファクトを使用しています。まとめルールエンジンは、ビジネスロジックの外部化を行い、ビジネスユーザがルールを記述出来るようにするための便利なツールです。特定分野における問題を効果的な方法で解決できます。他のアプローチと比較するとトレードオフが存在するので、その使用を決断するには系統的なアプローチが重要です。あなたが解決しようとしている問題と、あなたが成し遂げようとしていることを理解する汎用もしくは特定のルールエンジンが、それらのゴールにたどり着く助けとなるかを調査する一般的には、ビジネスルールの外部化やビジネスルールの変更に対する迅速な変化のサポート、ビジネスユーザによるビジネスルールの変更を促進したい、などのニーズがある場合は、ビジネスルールソリューションを考慮してもよいでしょう。あなたが、フロー制御の放棄によって新しいパラダイムを受け入れ、きめの細かいルールとオブジェクトを使用し、クロス乗積を回避し、ルールアプローチが生成しうる組み合わせと再帰について理解するなら、ルールエンジンを最大限活用することができるでしょう。考えても、あなたのニーズをルールエンジンが満たしてくれるかどうかわからない場合は、Droolsのようなフリーで利用可能なルールエンジンを使って、低コストでコンセプトを実証するための開発を行い、ルールエンジンがあなたの問題領域にとって適切かどうかを、自分自身で評価してみてください。ソリューションの一部にルールエンジンを採用すると決めたなら、ルールエンジンは設計と開発において多少の新しいスキルを必要とすること、あなたのチームがこうしたスキルを身につけるまでは開発コストや間違いがいくらか増えるだろう、と言うことを受け入れてください。その他のルールエンジンこの記事ではDroolsをサンプルのルールエンジンとして挙げましたが、その他にもオープンソース、商用問わず存在します。それらの完全なリストとその比較は、この記事の範囲を超えていますが、一般的なものを他にもいくつか挙げておきます。AdvisorJessJRulesOpenRulesPegaRulesRulesPowerこれらのルールエンジンの多く、特に商用製品では、この記事で詳しく述べたよりもより多くの機能、サービス、モジュール、コンポーネント、そしてツールを提供しています。ルールエンジンを選ぶ際、以下の事柄のうちいくつかを考慮することになるでしょう。ソフトウェア開発のジェネラリスト、ライター、たまにコンサルタントなど、全方位に対して熱心な人物です。ここ数年は金融サービス産業に重点を置き、為替取引ソリューション向けの顧客価値を管理する製品に従事しています。楽しみもしくは仕事のための開発、ソフトウェア仕様の読み書き、flickrへの投稿、ビデオゲームのプレイ、オープンソースコミュニティへの寄与、インターネット中の興味深いソフトウェアコンテンツを全て読もうという試み、そして彼自身のあらゆる楽しみの間に、彼はこの記事を書く時間を見つけてくれました。毎週火曜日に前週のまとめコンテンツがお送りいたします。25万人ものシニアデベロッパーのコミュニティーにぜひご参加ください。サンプルを見るあなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。登録するとさまざまなことができます。アカウント登録をしてInfoQをお楽しみください。あなたの意見をお聞かせください。毎週火曜日に前週のまとめコンテンツがお送りいたします。25万人ものシニアデベロッパーのコミュニティーにぜひご参加ください。サンプルを見る様々なイノベーターとアーリーアダプターがお送りするテクノロジーの概要を見る。自分がまだ知らないことに気づいていないと知るあなたが興味のあるトピックスをいつでも最新な情報に。あなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。よい世界へ私たちが暮らす世界を大切に思い、よりよいものにしたいと考えています。人のためのソフトウェア開発を加速し私たちのミッションを実現することで、この思いを成し遂げようとしています。私たちは利益の1%をさまざまな慈善団体に寄付しています。会社として、また従業員として、そうしたことの価値を強く信じているからです。with.プライバシーBTあなたのプロファイルは最新ですか?プロフィールを確認してアップデートしてください。アドレス*Eメールを変更すると確認のメールが配信されます。会社名:現在の会社名をご入力ください。Other組織規模:現在の組織規模をご入力ください。2,501+国:現在の国を設定してください。Zimbabwe都道府県:現在の都道府県に設定してください。次の都道府県にアップデートする:ニュースレターを購読しますか?インダストリーメールを購読しますか?本Eメールに登録すると、以前より関心のあったトピックの関連情報をお送りする場合がございます。詳細はこちらのプライバシーポリシーをご覧ください。newsletter?新しいメールアドレスに確認用のメールを送信します。このポップアップ画面は自動的に閉じられます。