物理モデル: アプリケーション アーキテクチャ
概念モデルと論理モデルが完了したら、アプリケーションの物理的な実装に関する決定を行うことができます。 物理モデルを作成するには、アプリケーションのさまざまなサービスが配置される場所と、その実装方法を理解する必要があります。 サービスを実装する方法の前に、さまざまなサービスが存在する場所を決定する必要があります。
さまざまなサービスが存在する場所を決定するための基本的なルールの 1 つは、使用されている場所にコンポーネントを配置することです。 たとえば、コンポーネントがベース クライアントの情報を表示する場合は、ユーザーのコンピューターに移動する必要があります。 コンポーネントがベース クライアントからの情報を検証する場合は、ベース クライアントのコンピューターにも存在する必要があります。 コンポーネントがデータベース内の情報を更新する場合は、データベース サーバー上に存在する必要があります。
もちろん、この規則に例外を設定する追加の考慮事項があります。 パフォーマンスとセキュリティの問題によって、コンポーネントが配置されている場所も決まります。 次の点について検討してください。
- コンポーネントは頻繁に変更され、更新プログラムの配布が困難になりますか?
- コンポーネントは、一般的なセキュリティ検証コンポーネントなど、他のアプリケーションで使用されますか?
- コンポーネントは、長い計算を行うか、サーバーにオフロードできる印刷などの機能を実行しますか?
- コンポーネントをサーバーに配置することで、コンポーネントのセキュリティを強化できますか?
アプリケーションのコンポーネントを適切に配置すると、システムまたはデータの場所が変更された場合に、開発チームがコストのかかる再コーディングから切り離すこともできます。 たとえば、ストアド プロシージャではなくデータ 層にデータ アクセス 規則を配置することで、アプリケーションは特定の DBMS への依存からより簡単に隔離されます。 変更が制限され、テストがコンパートメント化されるだけでなく、データ ソースを変更したり、アプリケーションを根本的に変更することなくデータを分散したりできます。
最後に、コンポーネントを検索する場合は、システム効率を活用する必要があります。 ビジネス オブジェクトをネットワーク上の一元化された場所に配置することは、時間とコスト効率に優れています。 オブジェクトはアプリケーション間で共有できます。また、コンポーネントをデプロイする前に単体テストを行うことができます。 また、ルールの変更は 1 つの時点でのみ発生するため、メンテナンス コストを削減することもできます。
関連トピック