アプリケーションの構造

どんなアプリケーションでも、他のアプリケーション上に構築できます。 どんなアプリケーションでも、コンポーネントを活用できます。 アプリケーションは、クラス継承、ルールセットのオーバーライド、限られた範囲での状況設定など、さまざまな方法で特殊化させることができます。 パターン継承は、アプリケーション内でのクラスに特殊化させるために使用できます。 直接継承は、上位層アプリケーションと下位層アプリケーションの間でのクラスに特殊化させるために使用できます。

上述したすべてが、「モジュラーアーキテクチャ」という用語で集約されます。今では、どのようなアプリケーション構造のアプローチを使用するべきかという議論はなくなりました。 今日唯一議論する内容は、アプリケーションのモジュール構造を定義する方法についてです。 構造の定義は、下方を検索して依存関係を特定する前にアプリケーション自体から開始します。 依存関係とは、あるアプリケーションを他のシステムにデプロイする前に、基盤となるアプリケーションやコンポーネントがあらかじめ存在する必要があることを定義します。

Application wizardタブでは、どのアプリケーションも、他のアプリケーションを構築できる再利用可能なアプリケーションとして自分自身を「宣伝」することができます。 1つのコンポーネントは、複数のアプリケーションでの使用を前提に設計されています。 New Application wizard ツールはまさにそれに該当し、フレームワークアプリケーションが唯一の組み込みオプションであったときから長い歴史を持つツールです。 Pegaは当初、フレームワークアプリケーションと実装アプリケーションの両方を同時に生成するオプションを提供していました。

アプリケーションを作成する場合、New Applicationウィザードでは最初に作成するアプリケーションのタイプを尋ねます。

Pegaが提供するコアアプリケーション以外のアプリケーションを選択した場合（ORG/Enterpriseアプリケーションを選択した場合など）、Pegaはそのアプリケーションから生成されるアプリケーションにケースタイプをインポートする場合があることを想定しています。 選択したアプリケーションのケースタイプをインポートしたくない場合は、「すべてのケースタイプを含める」チェックボックスをオフにするか、インポートしたくないケースタイプを個別にクリアすることができます。

CosmosやClassicなど、Pegaが所有するアプリケーションを選択した場合、New Applicationウィザードの動作が異なります。 クイックデモアプリケーションを生成する場合以外は、必ずAdvanced configurationをクリックして、新しいアプリケーションの「Work/Data/Int」クラス名プレフィックスのORGとAPPの部分を指定してください。

デフォルトでは、実装アプリケーションが生成されます。 生成されたアプリケーションには、ORG用に2つ、APP用に2つの計4つのルールセットが含まれます。生成されたこれらのルールセットは、初期のEnterprise Class Structure（ECS）を確立するクラスを開発しました。

Advanced configurationには、Framework かImplementationかを選択するオプションがあります。 Framework を選択した場合、New Applicationウィザードは、FWで終わり、ORG-FW-APPプレフィックスを持つクラスを含むルールセットを生成します。

Pegaがバージョン7.2.2で複数の組み込み（MBO）アプリケーションのサポートを開始したため、このFrameworkオプションは使用されなくなりました。 プロジェクト開始時に、ビジネスでフレームワークアプリケーションの活用を希望することを表明している場合のみ、このオプションを選択できます。

純粋に将来性を考えた場合は、Framework オプションを選択するべきではありません。 フレームワークアプリケーションを構築し、維持するためには余分な労力が必要です。 フレームワークアプリケーションを開発するために追加で必要な時間と労力は、その必要性を示す明確な根拠がない限り、正当化できません。

Pegaが提供するコアアプリケーション以外のアプリケーションで構築することを選択した場合、最終的には同じアプリケーション名の画面に移動し、Advanced Configurationリンクが表示されます。 インポート用に選択された任意のケースタイプは、同じ名前の生成済みケースタイプに直接継承されます。 生成されるアプリケーション内のワークプールクラスは、選択された組み込みのアプリケーション内のワークプールクラスも直接継承します。 生成されたワークプールクラスがWork-Cover-を拡張するように、後から変更することができます。

アプリケーションは1つのオブジェクトで、ケースタイプは複数のオブジェクトです。 それぞれの懸念事項は異なります。 アプリケーションは、そのルールセット内のWork/Dataクラスを所有しています。 ケースタイプは、アプリケーションのルールセットとは異なるルールセットと関連付ける必要があります。 （まだ定義されていない）コンポーネントアプリケーションに変換される可能性のあるケースタイプは、ケースタイプ固有のルールセットで作成する必要があります。 ケースタイプとアプリケーションのワークプールクラス内で定義されたルールとの間に依存関係を作らないようにしてください。 2つの異なるケースタイプが、同じ名前とタイプを持つルール（フィールドグループプロパティなど）を利用するからという理由で、アプリケーションのワークプールクラス内にルールを作成しないでください。 ビューは、フィールドグループのデータクラスに対して定義できます。 どちらのケースタイプでも、そのビューを再利用できます。

New Applicationウィザードで生成されるアプリケーション内には、常に2つのORGルールセットが含まれます。 ORGルールセットは、アプリケーション検証モードではなく、ルールセット検証モードを使用するように設定されます。

2つのORGルールセットを別のエンタープライズアプリケーションに配置するのは簡単なプロセスです。 エンタープライズアプリケーションのApplicationルールの関連ルールセットは、ORGルールセットである必要があります。 ORGクラスはWork-Cover-を拡張するため、ClassGroupレコードはORGクラスを作成できます。 Data-Portal を拡張するORG-UIPages クラスを作成し、エンタープライズアプリケーションのアプリケーションルールのUIクラスとして使用できます。

個別のエンタープライズアプリケーションを作成する理由は、デプロイメントの観点から他のすべてのアプリケーションと同じように扱えるようにするためです。 たとえば、エンタープライズアプリケーションでは、本番環境まで続くわけではないものの、独自のDevOpsパイプラインが存在する場合があります。

エンタープライズアプリケーションの異なるバージョンは、エンタープライズアプリケーションが構築されるPegaRULESアプリケーションのバージョンに基づいて定義できます。 同様に、エンタープライズアプリケーションに組み込まれたアプリケーションは、そのエンタープライズアプリケーションの特定のバージョンに依存することを宣言できます。