将来の機能を決定したとします。 次に、データを提供するユーザーまたはデータ、データを消費するユーザー/データ、およびシステム自体が実行する必要のあるデータ変換を正確に把握します。
一枚の紙と鉛筆を取ります。 能力に自信がない場合は、スキームを編集するための弾性バンドも使用します。 より高度な読者は、電子形式の建築設計のための専門的なツールに頼ることができます。
次に、データを転送または収集するためにシステムにアクセスするユーザーと、プログラムがアクセスする対象を見つけます。 プログラムに自分でアクセスするシステムまたはユーザーは、上部の紙片に模式的に描画します。 プログラムがアクセスするもの（データベースを含む）は以下のとおりです。
次に、UIまたはAPIという名前で上に描かれた各サブジェクトの下に長方形を描きます。これらは、ユーザーまたは外部制御システムがアクセスするインターフェースです。 UIがAPIにアクセスできる場合もあります。 すべての長方形を1つのアウトラインのUIと組み合わせて、プレゼンテーションレイヤーに名前を付けます。 すべての長方形をAPIと組み合わせて、サービスレイヤーと名付けます。
以下に示すシステムの場合、これらのシステムへのアクセスを担当するコンポーネントを指定します。 これらすべてのコンポーネントを1つの回路に結合し、データアクセス層と呼びます。
サービスレイヤーとデータアクセスレイヤーの間に、大きなアウトラインを描き、ビジネスロジックレイヤーと名付けます。 このアウトライン内の小さな長方形に、主要なビジネスタスクをリストします。 システムの1つのコンポーネントが1つのビジネス上の問題を解決します。
次に右側に、上から下にいくつかの長い長方形を描き、それらに書き込みます：ロギング、構成、パフォーマンスモニタリング、例外処理、およびプログラムのすべてのレイヤーの共通インフラストラクチャ（またはエンドツーエンド機能）です。
アプリケーションの論理アーキテクチャを取得しました。 サーバー間でレイヤーを分散させて物理アーキテクチャを取得します。
今、あなたはそれぞれの小さな正方形を詳細に解決する必要があります。
猫の下に小さな実用的な例を隠します。
例として、高校のパフォーマンス監視システムの完全に仮想的なプロジェクトを取り上げます。 私は2つの理由でそれを取るでしょう。 まず、私たち全員が学校に行きました。 第二に、私たちの多くと、子供たちは同じ学校にいます。 このため、主題領域がすべての人に明確になることを願っています。
したがって、私たちのシステムは、学生と電子教室の電子日記を維持するために設計されます。 さらに、システムに、学生、保護者、教師がメッセージを交換し、学校の管理者が学習プロセスを制御できる追加の機能セットを用意します。
そのため、学生、保護者、教師、学校管理者がシステムのユーザーになります。 さらに、ユーザーはシステム管理者となり、システム内のイベントに関する情報を受け取り、サービス操作を実行する必要があります。 ユースケースはリストせず、それらについてはリストしません。
ユーザーは、Webインターフェイスまたはモバイルアプリケーションを使用して、システムと対話します。 両方のユーザーインターフェイスは、独自のWebサイトを開発する余裕がない学校向けです。 残りは、Webサービスを介してシステムにアクセスできます。
電子日記、電子ジャーナル、教育プロセスと管理の組織の4つのサービスがあります。
サービス層の下には、ユーザーのビジネス上の問題を解決する多数のコンポーネントで構成されるビジネスロジックの層があります。
データはデータベースに保存されます。 さらに、軍事とアーカイブという2つの拠点があります。
システムはファイルからデータをエクスポート/インポートします。 さらに、システムがリモートで接続される2つの外部システムがあります。参照情報システムと教育省の情報システムです。
エンドツーエンド機能は、ロギング、監視、構成管理、およびセキュリティのメカニズムで構成されます。
その結果、次のようなシンプルなスキームが得られます。
これで、物理ノードを選択できます。 Webユーザーインターフェイスとサービスは、Webクラスターに展開されます。 ビジネスロジックとデータアクセスの層がアプリケーションサーバーに実装されます。 データベースは別のフェールオーバークラスターでホストされます。 後で、物理アーキテクチャの美しい図の形ですべてのノードを描くことが可能になります。
例が明確であることを願っています。
このトピックをより深く掘り下げるために、 「Microsoft Application Architecture Design Guide」に注意を払うことを提案します。 このマニュアルはリファレンス形式で書かれているため、システムの各レイヤーの設計に関する推奨事項をすばやく見つけることができます。