Skip to main content

特殊化とコンポーネントアプリケーション

特殊化とコンポーネントアプリケーション

アプリケーションを特殊化するアプローチを検討する場合には、アプリケーションをフレームワークとしてではなく、コンポーネントとして考えます。 コンポーネントとは、自動車の車輪やエンジンのように、全体を構成する1つの部品です。 これに対して、フレームワークとは、自動車のシャーシのように、基幹となる静的構造のことです。

補足: また、フレームワークは、基礎、モデル、テンプレート、設計図とも言います。

アプリケーションをコンポーネントとして使用する場合は、アプリケーションの構成にモジュール方式を採用することもできます。 また、アプリケーションを複数のコンポーネントアプリケーションで構成して定義できます。 

なお、コンポーネントアプリケーションを、Pega Platform™アプリケーションに追加できる小さな機能の作成に使用するルールセットの集合体としてのコンポーネントと混同しないでください。

コンポーネントとしてのアプリケーション

Pegaアプリケーションは、特にコンポーネントとして使用するために設計できます。 定義上、コンポーネントは再帰的です。 オブジェクトが他のオブジェクトを構成できるのと同じように、コンポーネントも他のコンポーネントを構成できます。 アプリケーションは、複数のアプリケーション上に構築できるため、この定義に当てはまります。

あるオブジェクトを「コンポーネント」という場合は、それが安定したインターフェイスを備え、公開された仕様に従って個別にテストできるということです。 コンポーネントアプリケーションは、独自の単体テストのルールセットを含む必要はありませんが、開発中に一時的に開発することは可能です。 デプロイする前に、単体テストのルールセットは、コンポーネントアプリケーション上に構築されたテスト専用のアプリケーションに移動されます。

同様に、コンポーネントアプリケーション内のケースタイプのテストデータ入力段階は、セルフテストにのみ有効となるように構成でき、残りの段階にテストデータを提供するために使用できます。 ケースタイプが本番環境でサブケースとしてのみ使用される場合は、「ケースがカバーされていない場合」と定義されたwhenルールによって回避できます。 本番アプリケーションが、テスト専用ステージを含むコンポーネントアプリケーション内のケースタイプを拡張する場合は、本番アプリケーションはそのケースタイプルールからそのステージを自由に削除できます。 

Hotel Component case

Pegaのコンポーネントアプリケーションは、オブジェクト指向プログラミング(OOP)の「開放/閉鎖の原則」に準拠しています。 これは、あるオブジェクトが他のオブジェクトによる使用をサポートするために、そのオブジェクト自体を変更する必要はないという原則です。 また、ユーザーオブジェクトに機能が追加されてもオブジェクトを変更する必要がないため、新しい要件をサポートする新しいコードが追加されたときに、メンテナンスに集中する波及効果を回避できます。  

Pega Platformで使用されているテンプレート設計パターンによると、ビジネスプロセスのモデリングは、開放/閉鎖の原則に準拠しています。 ユーザーが基礎となるアルゴリズムを基本クラスで定義します。 派生したクラスは、許可された拡張ポイントにコードを実装します。

レイヤーと複数の組み込みアプリケーション

組み込みアプリケーションを使用すると、共通コンポーネントとスタンドアロンコンポーネントをそのアプリケーションに合わせて分割します。 このモジュラー設計アプローチにより、アプリケーションを別のアプリケーションルールに指定できます。 その結果、アプリケーション間で必要なルールセットやバージョンの変更がより簡単に管理できるようになります。 また、複数の組み込みアプリケーションを使用することで、ルールセットの前提条件を使用する必要もなくなります。 代わりに、アプリケーション検証モードを使用することで、複数のアプリケーションにわたるルールセットの使用に関連するワーニングを回避できます。

組み込みコンポーネントアプリケーションを使用すると、機能がモジュール化され、再利用が促進されます。 組み込みアプリケーションは、ルールセットの前提条件よりもアプリケーション検証モードの使用を推奨します。 これにより、アプリケーション間で同じルールセットを使用することに関連するワーニングは回避されます。

Pega Platformが設計時に複数の組み込みアプリケーションの各種階層構造を処理する方法の詳細については、以下のPega Communityの記事とTech Talksを参照してください。 

補足: Pega Platform 7.2以前のPega Platformレイヤーのコンセプトは、単一の組み込みアプリケーション構成に基づいていました。 こうした構成では、時間とともにアプリケーション構造が複雑化し、メンテナンスが困難になりがちです。 たとえば、1つまたは複数のフレームワークとエンタープライズルールセットの組み合わせは、関連性のない複数のルールセットを含む可能性があります。 また、こうした組み合わせにより、直接管理していないアプリケーション定義のクローンを作成する必要が生じる場合もあります。 このような状況では、アプリケーション間で各種のルールセットやバージョンを再同期する必要が生じるなど、変更時に大量のアップデートが必要となります。

このトピックは、下記のモジュールにも含まれています。

If you are having problems with your training, please review the Pega Academy Support FAQs.

このコンテンツは役に立ちましたか?

改善できるところはありますか?

We'd prefer it if you saw us at our best.

Pega Academy has detected you are using a browser which may prevent you from experiencing the site as intended. To improve your experience, please update your browser.

Close Deprecation Notice