アーキテクチャ設計のダイアグラム
アーキテクトは、ダイアグラムを使ってコミュニケーションを取ることがよくあります。 ダイアグラムは、実装者や利害関係者が大まかなビジョンを確認したり、システムの機密性の高い領域や微妙な領域を深く掘り下げたりするのに役立つ強力なコミュニケーション ツールです。 意図を持ってコミュニケーションを行うには、アーキテクトはそれぞれの状況で役立つダイアグラムを選ぶ必要があります。
この記事のダイアグラムのリストは網羅的なものではありません。 ダイアグラムは、複数の種類が組み合わされていることがよくあります。
最終的に、アーキテクチャ ダイアグラムの選択は、伝えようとしている内容と対象者のプロファイルによって異なります。 アーキテクトは、設計、要件の調整、コミュニケーションのために、アクティビティ全体で複数の種類のダイアグラムを使用します。
ダイアグラム作成のプラクティス
ダイアグラムは、テキストによる説明を必要とせずに、重要な情報を提示します。 ダイアグラムではあいまいさを排除してください。 以下に、推奨事項をいくつか示します。
標準表記を使用します。 ダイアグラムの読みやすさと解釈を向上させるために、広く認識されている記号、アイコン、表示の規則を使用します。
あいまいな線は使わないでください。 ダイアグラムでは、エンティティ間のリレーションシップが線として示されることがよくあります。 線の使用方法に一貫性を持たせてください。
矢印のない線は使わないでください。 方向がないとリレーションシップがわかりにくいため、矢印を使用してください。 矢印のない線にはすべてラベルを付けて、リレーションシップを示します。
両端に矢印の付いた線は使わないでください。 両端の矢印は双方向の依存関係を意味します。 依存先 (クライアント) から依存対象 (サーバー) へのフローを表すには、片端の矢印を使用することをお勧めします。
すべてにラベルを付けます。 各アイコンに明確かつ正確でわかりやすいラベルを付けます。 リレーションシップが明確でない場合は、線にラベルを付けます。
一貫性を維持します。 ダイアグラム全体で同様の要素に対して、標準化された色、大文字と小文字、アイコン、アイコン サイズ、線の種類、矢印の先端、その他の表現を使用します。 ワークロードの設計とドキュメント用に作成されたすべてのダイアグラムで一貫性を保ちます。 既存のデータまたは分類から描画します。
正確であることが重要です。 ダイアグラムは抽象化ですが、プロセスの精度を犠牲にしないでください。 たとえば、仮想ネットワークを表す際に、その仮想ネットワーク内に存在しないサービスを表さないでください。 ダイアグラムはコミュニケーション ツールであるため、不正確な情報による誤解を避ける必要があります。
メタデータを含めます。 ダイアグラムに、そのダイアグラムの目的に関する重要な情報を提供するメタデータが含まれていることを確認します。 メタデータは、閲覧者がダイアグラムの範囲と重要性を理解するのに役立つコンテキストも提供します。 タイトル、説明、最終更新日、作成者、外部参照などの項目を含めます。
公式のアイコンとサービス名を使用します。 特定のテクノロジを表す場合は、テクノロジ プロバイダーの最新の公式アイコンを使用します。 テクノロジを識別することが重要な場合は、サービスの正式な名前を使用します。
例として、Microsoft サービスのアイコンを次に示します。
- Azure アーキテクチャ アイコン
- Microsoft 365 アイコン
- Microsoft Dynamics 365 アイコン
- Microsoft Entra ID アーキテクチャ アイコン
- Microsoft Power Platform アイコン
設計ダイアグラムの種類
ワークロード アーキテクチャは複雑で多次元です。 ディメンションの種類ごとに、そのディメンションに固有の詳細レベルを提供して、システムの特定の側面に焦点を当てます。 たとえば、フローチャートはプロセス フローを示します。 エンティティ リレーションシップ ダイアグラムは、システム コンポーネント間のリレーションシップを示します。
さまざまな種類のダイアグラムを使用すると、ディメンションを包括的に理解できます。 これは、利害関係者間の効果的なコミュニケーション、問題解決、意思決定を促進するのに役立ちます。
システムの概要図
システムの概要図は、ワークロード全体またはワークロード内のサブセクションの広範な概要として機能します。 これには、主要なコンポーネント、相互のリレーションシップ、システム内のデータ フローの大まかな順序が含まれます。 矢印は相互作用の方向を示します。
これらのダイアグラムは、共通の理解を得るのに役立ち、より深い議論を始めたり、利害関係者とのコミュニケーションを行ったりする際に有効です。
ブロック図
ブロック図は、ワークロードを主要な機能ブロックに分割します。 ブロックは通常、テクノロジに依存しません。 これらは、特定のコンポーネントではなく、実行されている機能を参照します。
たとえば、ブロック図は、特定のメッセージ バス テクノロジではなく、"メッセージング バス" を参照する場合があります。 この種類のダイアグラムは、細かい詳細で対象者の注意をそらすことなく、システムの構造、データ フロー、処理フローを説明するのに役立ちます。
コンポーネント図
コンポーネント図はブロック図のように機能しますが、一般的な機能ブロックが特定のテクノロジに置き換えられます。 これは、システムの個々のテクノロジ コンポーネントとその関係 (クライアント/サーバーなど) を伝達することを目的とした詳細なビューを示します。 これらのダイアグラムは、そのダイアグラムの範囲における視覚的な部品表のようなものです。
デプロイ図
デプロイ図は、ワークロード全体のインフラストラクチャ、商用市販の成果物 (COTS) ソフトウェア、カスタム コードのデプロイに焦点を当てています。 ソフトウェアとコードがホスティング インフラストラクチャ全体にどのように分散されているかを示します。
データ フロー図
データ フロー図 (DFD) は、データがシステム内でどのように移動するかを示します。これは、データ中心のシステムをモデル化する場合に役立ちます。 このようなダイアグラムでは、データがバッチで移動されるのかリアルタイムで移動されるのかを明記して、あいまいさを排除することをお勧めします。
シーケンス図
シーケンス図は、時間の経過に伴うワークロード コンポーネント間の通信交換を示します。 クライアント/サーバーのリレーションシップと、それらの同期または非同期の性質を示します。 また、これらの交換における依存関係を強調表示し、それらの中の障害シナリオを評価します。
ユーザー フロー図
ユーザー フロー図は、ワークロード、ユーザー、またはアクターとワークロードの間の範囲指定された相互作用に焦点を当てています。 ユーザーとユーザーのデータがシステムと相互作用するさまざまな方法にわたって、機能要件を明確にし、視覚化するのに役立ちます。
エンティティ リレーションシップ ダイアグラム
エンティティ リレーションシップ ダイアグラム (ERD) は、データベースまたは別のストレージ システムの構造を表すモデリング図です。 業界標準の属性と関連付けシンボルを使用して、エンティティ (テーブルなど) 間のリレーションシップを示します。
ネットワーク図
ネットワーク ダイアグラムは、ソリューションが実行される、または相互作用するネットワークの観点からそのソリューションを示します。 これらのダイアグラムは、ワークロードのネットワークのセグメント化、ネットワークの障害ポイント、インターネットのエグレス/イングレス ポイントなどの主要なネットワーク遷移を視覚化する場合に役立ちます。
ネットワーク ダイアグラムは通常、実装後も役立ちます。 ネットワーク ダイアグラムは、監査やインシデント対応でよく使用されます。
状態ダイアグラム
状態ダイアグラムは、特殊な視覚化です。 フロー (または個々のコンポーネント) が現在どの状態にあるかを示します。 また、条件やイベントに応じてフローがどのように状態間を遷移するかも示します。
フローチャート
フローチャートは厳密にはアーキテクチャ ダイアグラムではありませんが、設計を明確にするもう 1 つの方法です。 フローチャートは、複雑なワークフローやロジックを表すときに特に有用です。 これらを使用して、要件を調整したり、実装の選択を促進したりできます。
フローチャートは、ワークロードのインシデント対応計画に含めると有用です。これにより、重要な意思決定ポイントと、それに関連するアクションや通知チャネルを強調するのに役立ちます。