ArchitectureCanvasによるアプリケーションの検証
前回内容はこちら
今回はアプリケーション検証の4つのルールについて確認して行きます。
モジュールの検証ルールと混ざってしまうことが多いのでしっかり覚えたいです。
しつこいと思うのですがモジュール検証時のルールを一応キャプチャで載せておきます。
覚えたら本日の内容へ進みましょう。
アプリケーションの検証をするべき理由
Outsystemsファクトリーは複数のアプリケーションで構成されているため、各アプリのモジュール単位での検証のみではなく、アーキテクチャのアプリケーションレベルの検証が必要になってきます。
これをすることでアーキテクチャの健全性とデプロイの保守のしやすさの保証を得ることができます。
アプリケーション検証の4つのルール
アプリケーション検証時のルールは下記の通り4つあり、これらはよくテストで出るようなのでしっかり覚えて行きましょう。
ルール１：モジュールを適切に階層化する
ルール２：アプリケーションを適切に階層化する
ルール３：アプリケーションを所有者別に分ける
ルール４：スポンサー別に分ける
これらについて詳しく見ていきましょう
ルール１：モジュールを適切に階層化する
適切な階層化をするためには前回学習したモジュール関連ルール及び推奨事項を適用するだけでOK！
- レイヤー間で上方参照しない
- エンドユーザーモジュール間でのサイドリファレンスの禁止
- 循環参照しない
逆にこれらのルールを各アプリにしっかり適用しないと構成を適切にしようとしても無駄になってしまいます。
ルール２：アプリケーションを適切に階層化する
エンドユーザーアプリケーションは他のアプリケーションにサービスを提供することはできません。
例として、EndUserApp１（構成：エンドユーザーモジュールA、コアモジュールA、コアモジュールB（基盤B参照）、基盤モジュールB）と EndUserApp 2（構成：エンドユーザーモジュールB、コアモジュールC、基盤モジュールC）の2つのエンドユーザーアプリ間で
EndUserApp1のコアBをEndUserApp2のエンドユーザーモジュールBが参照している場合を考えます。
これはエンドユーザーアプリ間でのサイドリファレンスとなってしまっていて望ましくないです。
そのため、EndUserApp1及び２で使用しているコアモジュールB及び基盤モジュールBを共有アプリケーションとして分離して運用することが望ましいです。
ルール３：アプリケーションを所有者別に分ける
１つのアプリに複数の所持者がいると変更内容に対する責任の所在が不明確になるためデプロイ管理が複雑になってしまいます。
所有者を1人に絞れない場合はアプリケーションを分割して所有者を明確に定義することを検討しましょう。
所有者ごとにアプリを分割することで開発を円滑に進めやすいといったメリットもあります。
ルール４：スポンサー別に分ける
例えば複数の事業部がある会社を例に考えます。全ての事業部門に1つのアプリで対応すると、ある事業部門で加えた変更を個別にリリースすることはできません。つまり、最も進度の遅い事業部門に合わせてリリースサイクルが決まることになってしまいます。
そこで複数のアプリに分割して独立させると各事業部門がそれぞれの成果物のペースを決められるようになり各々でリリースを勧められるようになります。
一元管理する必要のある共通のコンポーネントやアプリを見極めたうえで、分離できそうなところを分離する必要があります。
まとめと次回予告
だいぶざっくりとした説明になってしまいましたが以下4つのルールを覚えたいです。
4つのルール
1.モジュールを適切に階層化する
2.アプリケーションを適切に階層化する
3.所有者別に分ける
4.スポンサー別に分ける
前回同様上記4つを覚えてからページを離れてくださると幸いです。
次回はアーキテクチャの検証ツールについて学習して行きます。
コメント