Skip to main content

 

 

 

 
Language:
 
 
 
OutSystems

適切なアプリケーションの構成のための4つのルール

再利用のニーズが認識されたら、アプリケーションの分割に対処することが常に必要になります。ただし、先行して1つのアプリケーションを複数の小さなアプリケーションに分割することは必ずしも自明ではありません。

アプリケーションの構成で4つのルールに従うことで、以下を実現することが可能になります。

  • 依存関係の最小化

  • デプロイの簡素化

  • ライフサイクルの独立性の促進

最初の2つのルールは、Architecture Canvasの手法を適切に使用した結果です。残りの2つのルールでは、他の戦略的な考慮事項を考慮に入れながら、より小さなアプリケーションを先行して作成する際の判断がしやすくなります。

ルール #1 - モジュールを適切なレイヤーに配置する

Architecture Canvasの原則に従います。モジュールアーキテクチャに違反があると、適切かつ管理可能なアプリケーションアーキテクチャを実現できない可能性があります。

ルール #2 - アプリケーションを適切なレイヤーに配置する

モジュールではなくアプリケーションに適用されるArchitecture Canvasの原則に従います。

ルール #3 - 所有者別に分ける

2つの異なるチームがそれぞれのプロジェクトを同時に進める場合、共通のサービスに影響を及ぼす両方のプロジェクトからの要件を受け入れるのが一般的です。ボトルネックを回避するために、両方のチームで共通のリソースを変更できるようにしたいと考えがちです。

1つのアプリケーションに複数の所有者を割り当てると、変更された内容に対する説明責任が不明確になるため、開発管理が複雑になります。

所有権の定義を促進することが重要です。1つのアプリケーションの所有権を1つに集中させることができない場合は、所有権を明確に定義するような方法でアプリケーションを分割することを検討します。

ルール #4 - スポンサー別に分ける

1つのプロジェクトが複数のスポンサーに影響を及ぼす場合、各LOB(業務部門)を別のアプリケーションに分離することが重要です。スポンサーごとに予算、要件、変化のペースが異なります。

以下の例は、異なるLOB(自動車保険、生命保険、損害保険)から各種保険シミュレータへのWebアクセスを許可する共通ポータルを示しています。

先行してアプリケーションをLOB別に分割すると、それぞれ独立して進化できます。共通のサービスをすべて分離することで、横断的な影響が予想されるため慎重に計画する必要があるものと、各LOB内で柔軟に変更できるものとが明確に区分けされます。

関連リソース

アプリケーションアーキテクチャを設計する方法の詳細については、「OutSystemsアプリケーションのアーキテクチャを設計する」のガイドをご覧ください。

アプリケーションランドスケープを構成する方法に関する推奨事項の詳細を確認することもできます。

  • Was this article helpful?