Skip to main content

 

 

 

 
Language:

 

 
 
 
OutSystems

Architecture Canvasをアプリケーションに適用する

アプリケーションアーキテクチャを分析する際、Architecture Canvasの原則はモジュールアーキテクチャと同様に重要な役割を果たします。

個別のモジュールをArchitecture Canvasで分類するのと同じ方法で、各アプリケーションもいずれかのレイヤーに配置されます。

アプリケーションは、その最上位モジュールレイヤーと同じレイヤーに配置する必要があります。以下の図は、各アプリケーションを構成するモジュールの性質に加えて、その最上位モジュールの性質を備えているアプリケーションを示しています。

各アプリケーションは、以下に示す同じ検証ルールに従って、アプリケーション間の関係を考慮します。

1.上方参照をしない

2.エンドユーザーアプリケーション間またはオーケストレーションアプリケーション間でサイドリファレンスをしない

3.2つのアプリケーション間で循環参照をしない

同じ原理がモジュールとアプリケーションに適用されます。オーケストレーションアプリケーションとエンドユーザーアプリケーションは、ライフサイクルの独立性を確保するために、再利用可能なサービスを提供しないようにします。たとえば、エンドユーザーアプリケーションには再利用可能なコアモジュールとライブラリモジュールを含めることができます。ただし、それらのモジュールが同じアプリケーションの他のモジュールのみで利用される場合に限ります。

アプリケーションとともにアーキテクチャを進化させる

アプリケーション間の依存関係について理解を深めるために、以下の一般的なシナリオについて検討します。

第1プロジェクト

通常、最初から複数のアプリケーションを定義することを検討することはありません。まず1つのプロジェクトに対して1つのアプリケーションから始めます。

第1プロジェクトでは、アーキテクチャ設計段階で考えられるすべてのモジュールを保持する新しいアプリケーションが作成されます。このアプリケーションはコンポーネントを組み合わせて成り立っており、それらのコンポーネントは最終的にバージョン管理されてQuality Assurance環境にデプロイされます。

第2プロジェクト

類似した第2プロジェクトでは、異なるビジネスプロセスに対応する別のアプリケーションが作成され、さらにいくつかのコアモジュールとライブラリモジュールが追加されます。

第3プロジェクト

その後すぐ、進化した第3プロジェクトで、エンドユーザー #1コアCの再利用を開始し、エンドユーザー #2コアBの再利用を開始します。モジュールアーキテクチャに関する違反はありませんが、2つのエンドユーザーアプリケーション間に相互のサイドリファレンス、つまり循環があります。

これは、2つのアプリケーションが密結合であることを明らかに示しています。第1プロジェクトの新しいバージョンをProductionにデプロイする場合は第2プロジェクトを一緒にデプロイする必要があり、その逆も同様です。

解決方法

以下の図に示すように、よく再利用されるリソースを新しいアプリケーション(コアアプリケーション)に分離する必要があります。

直接参照されるコアBコアCだけではなく、それらのすべての依存関係(ライブラリBライブラリC)もこのアプリケーションに移動することで、エンドユーザーアプリケーションへの上方参照を回避する必要があります。

この構成では、各エンドユーザーアプリケーションはそれぞれ異なるペースで個別に進化できます。また、コアアプリケーションによって、影響を管理するために慎重に進化する必要がある重要なリソースを分離します。

アプリケーションアーキテクチャの検証はDiscoveryツールを使用して実行することもできます。

アプリケーションを適切に構成する

アプリケーションを構成する際の重要なポイントに確実に対処するために役立つ4つのルールがあります。

考慮する必要があるもう1つの一般的な側面は、アプリケーションテーマを分離して、アプリケーション間で同じルックアンドフィールを共有することです。

関連リソース

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

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

  • Was this article helpful?