案内
技術普及の価値は、商用製品やオープンソースプロジェクトを通じてアプリケーションを構築する経路を短縮し、ビジネスのオンライン速度を加速するだけでなく、作業効率の改善、製品パフォーマンスの最適化、ユーザーエクスペリエンスの改善という点で優れたエンジニアの経験にも反映されます。共有して私たちの専門能力を向上させます。
次に、アリババの技術エキスパートの3つの絵画が、優れたアーキテクチャ図を描く際の独自の概念と経験をチームと共有し、あなたを助けることを願っています。
システムを1つまたは複数の写真で説明したい場合、次のような状況が頻繁に発生しますか？
- キャンバスから開始できません。もう一度削除してください。
- システムを写真で説明し、製品、運用、開発をわかりやすくするにはどうすればよいですか？
- 写真の半分を描いた後、観客は誰なのかはっきりしていませんか？
- 描かれた画像は製品の画像、機能的な画像、技術的な画像、またはホッジポッドですか？
- 画像にいくつかのフレームがあります。いくつかのフレームを追加しますか？
- レイアウトに満足できません...
同じ混乱がある場合、この記事では、アーキテクチャ図をより明確にする描画方法を紹介します。
最初にいくつかの基本的な概念を整理します
1.アーキテクチャとは？
アーキテクチャは、システム内のエンティティとエンティティ間の関係の抽象的な説明であり、一連の決定です。
建築は構造とビジョンです。
システムアーキテクチャは、概念の具体化であり、オブジェクト/情報の機能と形式要素の間の対応の割り当て、要素間の関係の定義、および要素と周囲の環境の間の関係の定義です。
良い仕事をすることは複雑な仕事であり、大きなトピックなので、この記事では取り上げません。アーキテクチャが整ったら、関係者は関連する決定を理解して従う必要があります。
2.アーキテクチャ図とは何ですか？
システムアーキテクチャ図は、ソフトウェアシステムの全体的な概要、さまざまなコンポーネント間の相互関係と制約の境界、およびソフトウェアシステムの物理的な展開とソフトウェアシステムの進化の方向を抽象的に表す全体図です。
3.アーキテクチャ図の役割
写真は千の言葉に値します。利害関係者がアーキテクチャの決定を理解して従うためには、アーキテクチャの情報を伝える必要があります。アーキテクチャ図は良いキャリアです。したがって、アーキテクチャ図を描くことは次のことです。
- コミュニケーションの障壁を解決する
- コンセンサスに達する
- あいまいさを減らす
4.アーキテクチャ図の分類
多くの情報を収集し、多くのカテゴリがあり、より人気のある4 + 1ビューがあります。これは、シーンビュー、論理ビュー、物理ビュー、プロセスビュー、開発ビューです。
★ シーンビュー
シーンビューは、システムの参加者と機能的なユースケースの関係を説明するために使用され、システムの最終的な要件と、通常はユースケース図で表されるインタラクションデザインを反映します。
★ 論理ビュー
論理ビューは、システムソフトウェア機能が分解された後のコンポーネントの関係、コンポーネントの制約、境界を説明するために使用され、システムの全体的な構成とシステムの構築方法を反映します。通常、UMLコンポーネント図とクラス図で表されます。
★ 身体の様子
物理ビューは、システムソフトウェアと物理ハードウェア間のマッピング関係を説明するために使用され、システムコンポーネントが一連のコンピューターノードに展開される方法を反映します。これは、ソフトウェアシステムの展開と実装プロセスをガイドするために使用されます。
★ プロセスフロービュー
プロセスフロービューは、システムソフトウェアコンポーネント間の通信シーケンス、データの入出力を説明するために使用され、システムの機能フローとデータフローを反映します。通常、シーケンス図とフローチャートで表されます。
★ 開発ビュー
開発ビューは、システムのモジュール分割と構成、および内部パッケージに洗練された構成設計を説明するために使用され、開発者にサービスを提供し、システム開発の実装プロセスを反映します。
上記の5つのアーキテクチャビューは、ソフトウェアシステムのさまざまな機能をさまざまな角度から表しており、これらを組み合わせてシステムアーキテクチャをアーキテクチャの青写真として説明しています。
どのようなアーキテクチャ図が良いアーキテクチャ図ですか？
上記の分類は以前の経験の要約であり、写真もインターネットから取得されているので、これらの写真は良いですか？ひょうたんスクープで描いてみませんか？
これらの図の品質については心配しないでください。これらの図の分類と機能について考え、それらをまとめました。適切なアーキテクチャ図を描く前に、まずその対象者を明確にし、次に明確に考える必要があると考えていますどのような情報を彼らに渡すのか、つまり、物理的なビューを描画して物理的なビューを描画したり、論理的なビューを描画して論理的なビューを描画したりしないでください。ただし、異なる聴衆によると、伝えられる情報は画像で正確に表現する必要があります。図はそのようなカテゴリーにあるかもしれません。したがって、描画の品質の直接的な基準は、聴衆が伝えたい情報を正確に受け取ったかどうかです。
これら2つのポイントを明確にした後、聴衆の観点から、優れたアーキテクチャ図は説明する必要はなく、自己記述的であり、コードをエコーできるように一貫性と十分な精度が必要です。
アーキテクチャ図の描画で発生する一般的な問題
1.ボックスは何を表していますか？
なぜ円の代わりにボックスを適用するのですか、それは特別な意味を持っていますか？ボックスやその他の形状を自由に使用すると、混乱が生じる可能性があります。
2.破線と実線はどういう意味ですか？矢印はどういう意味ですか？色はどういう意味ですか？
線や矢印をランダムに使用すると、誤解が生じる可能性があります。
3.ランタイムとコンパイル時間の間に矛盾がありますか？レベルの矛盾？
アーキテクチャーは複雑なタスクであり、単一のダイアグラムのみを使用してアーキテクチャーを表すことは、説明できない意味上の混乱を簡単に引き起こす可能性があります。
この記事で推奨される描画方法
C4モデルは、コンテナー（アプリケーション、データストレージ、マイクロサービスなど）、コンポーネント、およびコードを使用して、ソフトウェアシステムの静的構造を記述します。このような絵は比較的描きやすく、描き方のポイントも記されていますが、最も重要なのは、絵の種類や考えられる聴衆や意味を明確に示していることです。
次のケースは、C4公式Webサイトからのものであり、ソフトウェアアーキテクチャをより適切に表現する方法を理解するために、いくつかの理解を追加します。
1.コンテキスト図
架空のインターネットバンキングシステムで、外部のメインフレームバンキングシステムを使用して顧客のアカウントと取引情報にアクセスし、外部の電子メールシステムを介して顧客に電子メールを送信します。非常にシンプルで明快であることがわかります。説明は不要で、すべて理解されていると思います。構築する必要のあるシステム自体、システムのお客様、システムとやり取りする周辺システムが含まれています。
★ 使い方
このような単純な図から、システムの構築対象、ユーザーは誰か、システムを誰が使用するか、既存のIT環境にどのように適合するかがわかります。この写真の対象者は、開発チームの内部担当者、外部の技術担当者または非技術担当者です。つまり：
- 構築されたシステムは何ですか
- 誰が使うか
- 既存のIT環境に統合する方法
★ 描き方
中央には、ユーザーや他の相互作用するシステムに囲まれた独自のシステムがあります。この図の要点は、構築するシステムのユーザーと高レベルの依存関係を整理することであり、図面を整理するのに数分しかかかりません。
2.コンテナ図
コンテナマップは、コンテキストマップで構築されるシステムの拡張です。
上の図では、ユーザーと周辺システムに加えて、構築されるシステムには、java \ spring mvcに基づくWebアプリケーションが含まれ、システムの機能の入り口を提供します。xamarinアーキテクチャに基づくモバイルアプリは、モバイル端末の機能の入り口を提供し、Javaベースのapiアプリケーションはサービスを提供します、mysqlデータベースがストレージに使用され、さまざまなアプリケーション間の相互作用が矢印線で記述されます。
この写真を見ると、四角い箱なのか丸い箱なのか、実線の矢印なのか点線の矢印なのかは気にせず、矢印の向きもあまり目立ちません。
描画にはさまざまな方法があり、すべてがフレームと線の意味を定義します。これには、絵を描く人と絵を見る人がこれらの定義を明確に理解して、全体像の情報を読み取ることが必要です。現実には、これは非常に高い要件であるため、多くの写真は大まかな意味しか見ることができません。
★ 使い方
この写真の対象者は、チーム内外の開発者か、O＆M担当者です。用途は次のようにリストされます。
- ソフトウェアシステムの全体的な形状を示します
- 高度な技術的決定を反映
- システムの責任がどのように分散され、コンテナがどのように相互作用するか
- 開発者にコードを書く場所を教える
★ 描き方
ブロックダイアグラムで表すと、内部には名前、技術的な選択、責任、およびこれらのブロックダイアグラム間の相互作用が含まれることがあります。外部システムが関係する場合は、境界を定義するのが最善です。
3.コンポーネント図
コンポーネント図は、コンテナを展開し、その内部モジュールを説明するものです。
★ 使い方
この図は、主に内部開発者向けであり、コードを編成および構築する方法を示しています。その用途は次のとおりです。
- システムを構成するコンポーネント/サービスについて説明します
- コンポーネント間の関係と依存関係を明確化
- ソフトウェア開発がデリバリーを分解する方法のフレームワークを提供します
4、类图（コード/クラス図）
この写真は明らかに技術担当者向けであり、より一般的であるため、詳細には紹介しません。
ケース共有
以下は、内部リアルタイムデータツールのアーキテクチャ図です。自己記述型のアーキテクチャ図であるため、ここではあまり説明しません。理解できないことがあるなら、それは絵が十分ではないに違いない。
アーキテクチャ図を描く方法はたくさんあるかもしれませんが、この記事では主にC4の方法を紹介し、C4の理論は常に進化しています。しかし、どの描画方法を使用しても、描画とコミュニケーションの元の意図に戻るので、描画の過程でフレームに制限される必要はありません。要するに、絵を描く前にそれについて考えてください。誰に絵を描くか、何を見るか、説明なしでどのように理解するか。
著者について：3つの絵画、アリババの技術専門家、Zi Jing、Peng Sheng、Yu Leもこの記事に寄稿しました。3つの絵画が長年ワークフローエンジンの研究開発に携わっており、現在は並行性の高いモバイルインターネットアプリケーションのアーキテクチャと開発に焦点を当てており、この記事の寄稿者はAlibaba小売通信部門からのものです。
参考資料：
C4公式サイト：https://c4model.com/
ソフトウェアアーキテクチャ図が必要な理由：
https://www.infoq.cn/article/GhprrUlOYyOqS8*FR1pH
書籍：「プログラマーはソフトウェアアーキテクチャを読む必要がある」
Alibaba P7の技術エキスパートが、1〜5年働いたJavaエンジニアのコア競争力を改善する方法について話します
Javaプログラマーは、大きな工場に入るのに必要なアーキテクチャーの知識を必要とします：K8S + Nginx + SB + SC + docker
