新しいビジネス分野へのアプリケーションの拡張
4 タスク
30 分
シナリオ
Front StageはOperaという会社を買収します。 両社は、顧客がイベントの予約やゲストの受け入れを行うためのサポートを提供するという、類似のビジネスモデルを持っています。 ただし、Operaは屋内イベントのみを管理し、駐車場や天候に対する準備に関連するタスクは行いません。 Front Stageと同様に、Operaもイベントのためにホテル客室の予約を行えるようにする必要があります。
Front Stageは、既存のアセットを再利用して、Operaのビジネスモデルをサポートし、推進したいと考えています。 一方で、Front Stageは、屋外でのイベント開催というビジネスモデルに制約を課したくありません。
詳細なタスク
1 設計オプションの特定
ソリューションは、Front Stageのホテル客室予約機能をOperaが再利用できるものでなければなりません。
オプション1
既存のHotelアプリケーションをベースにした新しいOperaアプリケーションを作成します。 この新しいレイヤー内のクラス名は、FSG-OPRA-で始まります。
オプション2
既存のEvent Bookingアプリケーションをベースにした新しいOperaアプリケーションを作成します。 Operaは、Front Stageの新しい部門として定義します。 この新しいレイヤー内のクラス名は、FSG-OPERA-OPRAで始まります。
2 設計オプションの評価
|
設計 |
長所 |
短所 |
|---|---|---|
|
Event Bookingアプリケーションをベースにする。 Operaは1つの部門である。 |
|
|
|
Hotelアプリケーションをベースにする。 Operaは部門でない。 |
|
|
3 最適な設計オプションの提案
HotelアプリケーションをベースとしてOperaアプリケーションを構築する方法には柔軟性があります。 Operaアプリケーションに影響を与えるのはHotelアプリケーションのリリースサイクルのみであり、これは、Event Bookingアプリケーションほど複雑ではありません。 このアプローチでは、Operaを部門として定義したためにクラス名が長くなってしまうことがありません。 Operaの組織は、Opera関連のすべてのアプリケーションが利用できる、FSGルールセットと同様のルールセットを自由に作成できます。
4 必要な設計と構成のタスクの特定
ビジネスシナリオに合った最適なアプローチを決定するために、可能なソリューションを設計し、比較します。 最初に分析結果の概要を示し、続いて各ソリューション案の詳細な検討と比較を行います。 提案されたソリューションを実装します。
Room Requestケースタープは、Operaアプリケーションに含まれるOperaイベントの子ケースです。 Rooms Requestをインスタンス化するOperaEventケースタイプのライフサイクルにHotelステージを作成します。
Rooms Request子ケースを作成するために必要な初期値をキャプチャするための初期のEnter Test Dataステージを含めることで、OperaEventケースタイプを自己テストできるようにします。
上書きが必要なルールを FSG-Hotel-Workのサブクラスから適切なFSG-Opera-Workのサブクラスにコピーします。以下に例を示します。
- pySetFieldsDefaults （FSG-Hotel-Work-RoomsRequestクラス）
- InitRoomsRequest フローアクション、データトランスフォーム、セクション
- PreSaveHotel データトランスフォーム
- AddHotelInfo フローアクションとセクション
- SearchHotel フローアクションとセクション