Skip to main content

 

 

 

 

Template:OutSystems/Documentation_KB/Breadcrumb_New_Layout

 

Template:OutSystems/OSLanguageSwitcher
Language:

 

 

 

 

 
OutSystems

アーキテクチャから開発へ

この一連の記事では、アーキテクチャ設計図を実際のOutSystemsアプリケーションに変換する方法について説明します。

この記事では、主にアプリケーションのアーキテクチャ設計図を作成する方法について説明します。2つ目の記事では、設計図に基づいてアプリケーションの開発を開始する方法について説明します。また、コードの例も示されているため、実行するコーディングとアーキテクチャのベストプラクティスを評価できます。

アーキテクチャ設計図の作成

Soccer Fields Fictitiousという顧客が、利用者がサッカー競技場をオンラインで予約できるWebアプリケーションを作成する場合を考えます。

免責事項: これは架空の顧客に基づく仮想のユースケースです。

要件

アプリケーションの要件は以下のとおりです。

  • サッカー競技場と各競技場の特徴(規模、空き状況、1時間あたりの料金など)のリストを表示する機能

  • 利用者がサッカー競技場を選択して予約する機能

なお、サッカー競技場のリストは外部システムによって提供されます。つまり、実際の競技場の管理や決済の処理はこのアプリケーションのスコープに含まれません。

アーキテクチャ設計プロセス

アーキテクチャ設計プロセスは、3つのステップのアプローチに従って行います。

ビジネスコンセプトと連携ニーズの開示
アーキテクチャレイヤーキャンバスでのコンセプトの整理
適合する推奨パターンのアセンブル

満足できる設計になるまでこれら3つのステップを何度も繰り返す必要があることを理解することが重要です。また、後で新しいコンセプトや詳細が見つかった場合は、実装中にプロセスを繰り返す必要があります。

この記事では、シンプルなアプリケーションを示し、繰り返しを1回のみ行います。

(ビジネスコンセプトと連携ニーズの)開示

まず、機能要件と非機能要件を把握します。このステップでは、できる限りすべてのユーザーストーリーを見つけ出し、連携ニーズや求められるUXを把握する必要があります。

機能要件

  1. 以下のフィルタを使用して競技場を検索します。

    • 競技場の名前
    • 都市
    • 競技場の規模(同時にプレイできる利用者の人数)
  2. 利用予定者が競技場を予約できます。

非機能要件

  1. 入手可能な主要なブラウザに対応します。

  2. REST APIを利用して、外部システムからサッカー競技場のリストを取得します。

  3. システムがオンラインで動作し、UIがモバイルデバイスに対応している必要があります。

(Architecture Canvasでのコンセプトの)整理

Architecture Canvasの原則を簡単にまとめます。

レイヤー 説明
エンドユーザーレイヤー ユーザーインターフェイスおよびプロセス。コアライブラリを再利用してユーザーストーリーを実装します。
コアレイヤー ビジネスコンセプトに関連するサービス。再利用可能なエンティティ、ビジネスルール、ビジネスウィジェットをエクスポートします。
基盤レイヤー フレームワークを拡張するビジネスに依存しないサービス。再利用性の高いアセット、UIパターン、外部システムへのコネクタ、ネイティブコードの連携が含まれます。

この記事では、アーキテクチャ設計プロセスではなくアーキテクチャから開発までのプロセスについて主に説明するため、この部分に関しては要点のみを説明します。Architecture Canvasや設計プロセスの詳細については、OutSystemsのアーキテクチャに関するオンライントレーニングをご覧ください。

これらの原則に基づき、最終的にレイヤーキャンバスで以下のようなアプリケーションのコンセプトになりました。

アーキテクチャレイヤーキャンバス

特定した主なコンセプトは以下のとおりです。

  • SoccerFields: ユーザーとのインタラクションを制御するメインアプリケーション。

  • Bookings: 利用者が競技場を予約できるという機能要件。

  • Players: アプリケーションを使用し、競技場を利用/予約する利用者。

  • Fields: 利用者が検索や予約を行うときに使用する主な競技場のコンセプト。

  • Fields Integrations: サッカー競技場は外部システムに保存されるため、APIを使用して外部システムに接続するための非機能要件モジュールが必要です。

  • Soccer Fields Theme: アプリケーションのルックアンドフィールがモバイルに対応している必要があります。

(適合する推奨パターンの)アセンブル

次は、アセンブルです。ここで関係する原則を思い出しましょう。

  • 関連するコンセプトがある場合は統合します。
  • 複雑すぎるコンセプトやライフサイクルが異なるコンセプトは統合しません。
  • コンシューマが関わらないすべての連携ロジックから再利用可能なロジックを分離します。

これらの原則に基づき、アーキテクチャパターンとベストプラクティスを踏まえ、この記事では以下のコンセプトについて主に説明します。

オンライン: 外部APIにアクセスするには、Field_IS eSpaceを使用します(ISは連携サービスを意味します)。このモデルは外部APIを認識し、内部アクセスのためにデータを正規化します。そのため、Field_CS eSpaceとField_Sync eSpaceはAPIの特殊性を認識する必要がありません。これは抽象化の面で非常に重要です。このパターンを使用することで、アプリケーションがAPIの変更の影響を受けにくくなり、データモデル内にAPIから不要なものを取り入れなくてすみます。

バッチ同期: この2つ目のパターンを使用すると、フィルタがスムーズになり、(パフォーマンスを高めることで)ユーザーエクスペリエンスが向上します。Fieldエンティティの概要をローカルに保持し、外部APIにアクセスせずにローカルエンティティで主な検索を行うことができます。これを実現するため、Field_Sync eSpaceが競技場データを1日に1回同期します。

以下の図は、これらのパターンの設計を示しています。

ビジネスロジックモジュール: 複雑さや構成を管理したり、独自のライフサイクルにしたりするため、ビジネスロジックBL、アクション)やコアウィジェットCW、Webブロック)を分離することも推奨します。この場合、_CW eSpaceを作成する必要はありませんでした。おそらく後で作成することになりますが、現在のところ、Booking_BL eSpaceが必要なすべてのビジネスロジックに対応しています。

これらのアーキテクチャパターンを適用し、一般的な命名規則をモジュール名で使用すると、最終的なモジュールのアーキテクチャ設計図は以下のようになります。

アーキテクチャ設計図

各モジュールの主な機能と役割は以下のようになります。

  • SoccerFields: サッカー競技場の検索と予約を行うためのすべての画面を含むエンドユーザーアプリケーション。

  • Booking_BL: 競技場と利用者のコンセプトのロジックを組み合わせた、予約の管理に関連するすべてのロジックを含みます。

  • Player_CS: 予約者のエンティティや関連するエンティティを含む再利用可能なコアサービス。

  • Field_CS: 外部データのローカルレプリカ、つまり、競技場のエンティティと関連するエンティティをホスティングする再利用可能なコアサービス(コールドキャッシュ)。

  • Field_Sync: 外部システムからField_CSにデータを同期するロジック。このモジュールは、すべてのロジックを分離し、競技場のエンティティの概要のみを含むコールドキャッシュを保持します。

  • Field_IS: Field APIの利用と正規化を行う技術的なラッパー。このモジュールは抽象化を行い、外部APIのすべての特殊性を認識します。

  • SF_Th: Soccer Fieldアプリケーションの主要なルックアンドフィールに関するテーマモジュール(非機能)。

アプリケーションの構成

モジュールを作成するときだけではなく、アプリケーションを作成するときにもアーキテクチャについて検討して、アプリケーショをどのように配置するかについて考える必要があります。

OutSystemsアプリケーションはService Studioで定義されたモジュールのセットであり、LifeTime(OutSystemsでアプリケーションライフサイクル管理を行うツール)の最小デプロイユニットになります。

以下の図について考えます。

OutSystemsアプリケーションのモジュールのセット

アプリケーションはモジュールが必要とするレイヤーに従う必要がありますが、アプリケーションレイヤーを定義するのはアプリケーションの中にあるモジュールの最上位のレイヤーです。つまり、アプリケーションが基盤レイヤーのモジュールのみで構成されている場合、このアプリケーションは基盤アプリケーションになります。基盤レイヤーのモジュールを含み、さらにコアレイヤーのモジュールも1つ以上含む別のアプリケーションがあった場合、このアプリケーションはコアアプリケーションになります。

Soccer Fields Appのアプリケーションの構成を以下に示します。

Soccer Fields Appの構成

ここには、2つのアプリケーションがあります。

  • Soccer Fields App: SoccerFieldsユーザーモジュールが含まれます。ユーザーが操作し、スタイルのカスタマイズにも使用されるフロントエンドアプリケーションです。アプリケーションに適用されるカスタムスタイルがある場合、SF_Thモジュールも含まれます。

  • Field Core Services: 競技場に関連するすべてのモジュールが含まれます。

最終的なアーキテクチャ設計図を実行に移す方法の詳細については、「アーキテクチャ設計図からの開発」をご覧ください。