プロジェクト階層の設定
プロジェクト間の依存関係を確立して、階層を作成します。 ルール・プロジェクトの階層を使用して、特にアプリケーションの複雑さが増していく場合など、ルールと BOM をいろいろなプロジェクトに分離して共有します。 異なるルール・プロジェクトを使用することで、保守容易性が高まり、ロジックのいろいろな部分を独立してテストできたり、さまざまな意思決定ポイントに応じた編成が可能になったりします。 このようにしてから、プロジェクトが相互に参照するように設定します。
ルール・プロジェクト構造の編成
意思決定サービスは、プロジェクト構造の作成を容易にするように設計されています。 意思決定サービスを作成するときは、ルール・プロジェクト階層のトップレベル・プロジェクトとして機能するメイン・ルール・プロジェクトを作成します。 プロジェクトに多数のルールが含まれている場合は、他のタイプのプロジェクトを作成して、これらのルールをドメイン別にグループ化し、BOM を保存します。 次に、プロジェクト間の依存関係を設定します。 メイン・プロジェクトによって直接的または間接的に参照されるすべてのプロジェクトは、意思決定サービスの一部になります。 例えば、メインの意思決定プロジェクトは 2 つの標準ルール・プロジェクトを参照して、その両方が、BOM を含む 1 つのプロジェクトを参照する場合があります。 4 つのプロジェクトすべてが意思決定サービスを形成します。
- 「メイン・ルール・プロジェクト」を選択して、意思決定サービスのエントリー・ポイントであり、他のプロジェクトを参照する可能性のあるプロジェクトを作成します。
- 「標準ルール・プロジェクト」を選択して、ルールを格納するプロジェクトを 1 つ以上作成します。
- 「BOM のあるルール・プロジェクト」を選択して、BOM を格納するプロジェクトを作成します。
で、任意のプロジェクトのタイプを変更してメイン・プロジェクトに変換したり、その逆に変換したりすることができます。 ルール・プロジェクトが別のプロジェクトによって参照されていない場合は、ルール・プロジェクトをメイン・ルール・プロジェクトに変更できます。 プロジェクトを変更すると、プロジェクトが相互に参照する方法を変更しなければならない可能性があり、プロジェクトの配布と同期に影響する可能性があります。
Rule Designerでは、ビルド、クエリー、リファクタリング、ルール・セット抽出など、多くの操作が意思決定サービス・レベルで行われます。 結果として、個別の意思決定サービスにルール・プロジェクトをグループ化すると、これらの操作の範囲が制限されます。
次の図は、ある意思決定サービスで構成可能なルール・プロジェクト編成を示しています。 メイン・プロジェクトには、階層内のプロジェクトのルールを使用するルール・フローが含まれ、それらのプロジェクトはプロジェクトの 1 つに保持されている BOM を共有します。 ルール・プロジェクト 2、3、および 4 は、メイン・ルール・プロジェクトによって直接的または間接的に参照されるため、4 つのプロジェクトはすべて同じ意思決定サービスの一部です。
複数ルール・セットのプロジェクト構造の編成
クライアント・アプリケーションがそれぞれ異なる意思決定ポイントを呼び出す場合、複数ルール・セットのプロジェクト構造を編成する必要があります。
操作とそのルールが BOM の一部のみを必要とする場合は、それらのルールと BOM のその部分を、それらのルールで使用可能な語彙が指定された別個のルール・プロジェクト階層に保持できます。 BOM のサイズは、使いやすさやパフォーマンスの問題に影響を与えることがあります。 ルール・エディターでの入力エントリーの数を減らし、ルールとの関連性を高めるには、カテゴリーを使用して語彙をサブセットに編成します。
すべての意思決定操作、ルール・フロー、およびルールを同じ意思決定サービスにパッケージすることができます。 以下の図に、意思決定ポイントを別々のルール・プロジェクトに分散させるように設計された意思決定サービスを示します。 図には、効果的に BOM を分割するための戦略も示されています。
