記事「アーキテクチャの文書化：はじめに」を読み、上記を別のアプローチで説明することにしました。
私はテキストで図を描きません、Archimate言語でそれらを読んでみてください。エジプトの象形文字を解読することを想像してみてください。ここにヒントがあります-言語表記の要約をデコードするための文字セット
動機と戦略の説明
以前 に紹介した定義を思い出させてください：
アーキテクチャは、一連の設計ソリューションを目的に対応するシステムに編成する設計ソリューションです。
したがって、システムの目的を決定する必要があります。目標や要件を直接設定することはありませんが、JTBDアプローチを使用してより大規模に検討することができます。
ビジネス層とアプリケーション層
「Man」が利用可能な選択肢から情報製品「Blog」を選択したと仮定します。
製品はデジタルであるため、ビジネス層（機能アーキテクチャ）とアプリケーション層（アプリケーションアーキテクチャ）をすぐに接続できます。
同時に、モデレートには時間リソースが必要なため、「コメント」および「コメントの管理」サービスはまだ使用されません。
技術層（技術アーキテクチャ）
ブログには多くのプラットフォームがあり、最初から何も実装する必要はありません。特定のプラットフォームを選択するには、要件に基づいて比較表を作成する必要があります（残念ながら、これは指定されていません）。他の基準で補足することができます。ここではすべてが明確だと思います。Ghost CMS、Apache HTTP Server、MySQLを選択したとしましょう。
次に、これらすべてをいくつかのインフラストラクチャに配置する必要があります。これも、関連する基準に従って選択します。GCPにします。
概要
まあ、それだけです。はい、説明がほとんどないことは理解しています。
どのような疑問が生じる可能性があります：
1）すべての情報を1つの画像に配置することは可能ですか？
回答：はい、接続を制御する必要がある場合は可能です。ただし、バランスを維持し、レイヤー（ビジネス、応用、技術など）を慎重に組み合わせる必要があります。作成するチャートの数が少ないほど、不一致が発生する可能性は低くなります。図の要素が多いほど、意味を理解するのが難しくなります。したがって、バランスが必要です。
2）ビューポイントの概念を使用できますか？
回答：はい。ただし、ビューが互いに一貫して整列していることを確認してください。そうしないと、図を読む人に同意する必要があります。項目1を参照）
