Community

By Ding Yi, nicknamed Sanhua at Alibaba.

技術コミュニケーションの価値は、商用製品およびオープン ソース プロジェクトを通じてアプリケーションが開発され、さまざまなビジネスの立ち上げプロセスが加速する方法のみに反映されるわけではありません。 しかし、その価値は、生産性の向上、製品性能の最適化、ユーザー体験の促進において、複数の異なる優秀なエンジニアが共有する経験にも大いに反映されます。

この記事では、アリババの技術専門家である丁乙が、効果的なアーキテクチャ図の作成に関する彼のアイデアと経験を紹介します。

1つまたは複数の図でシステムを説明するために、私たちはしばしば次の問題に遭遇します。

• どこから始めればよいかわからない。
• 関連する製品、運用、開発チームが明確に理解できるように1つの図でシステムを説明する方法がわからない。
• 途中で読者が誰であるかを知らないことに気づいた。
• 製品の機能図を描いているのか、技術図を描いているのか、単に混合しているのかがわからない。
• 図のボックスが少なすぎると、他に何を追加すればよいかわからない。
• 図のレイアウトに決して満足しない。

同じ問題にぶつかった場合、この記事では明確なアーキテクチャ図を作成するための描画方法を紹介します。

コンセプト

アーキテクチャとは何か

「アーキテクチャ」は、システム内のエンティティおよびそれらの間の関係性を抽象化して説明するものと定義することができます。 4898>

「システムアーキテクチャ」は概念の具体化であり、モノや情報の機能と形式的な要素との対応関係の分布です。 要素間の関係だけでなく、要素と周囲の環境との関係も定義します。

健全なアーキテクチャを構築することは複雑な作業であり、ここで議論するのは素晴らしいトピックです。 アーキテクチャを構築した後、関係者はそれを理解し、その指示に従わなければなりません。

アーキテクチャ図とは何か

アーキテクチャ図は、ソフトウェア システムの全体概要とコンポーネント間の関係、制約、および境界を抽出するために使用する、システムの図である。

アーキテクチャ図の機能とは

図は、百聞は一見に如かずです。 言い換えれば、アーキテクチャ図はいくつかの異なる機能を提供する必要があります。 関連するユーザーがシステムアーキテクチャを理解し、意思決定においてそれに従うことができるように、アーキテクチャに関する情報を伝達する必要があります。 アーキテクチャー図は、これを行うための素晴らしい方法を提供します。 いくつかの主要な機能を置くと、アーキテクチャ図は次のことが必要です。

• コミュニケーションの障壁を取り除く
• 合意に達する
• 曖昧さを減らす

アーキテクチャ図の種類

図は多くのカテゴリに分類することができる。 一般的なダイアグラムの 1 つは 4+1 ビューで、アーキテクチャのシナリオ、論理、物理、プロセス、および開発ビューを含みます。

シナリオ ビュー

シナリオ ビューは、システム参加者と機能ユース ケース間の関係を記述し、システムの最終要件と相互作用設計を反映させます。 このビューは、一般的にユースケース図です。

論理ビュー

The logical view is used to describe the component relationships, component constraints, and boundaries after the breakdown of system software functions.

Logical viewは、システムのソフトウェア機能の分解後に、コンポーネント関係、コンポーネント制約、境界を記述するために使用します。 これは、システム全体の構成とシステムの構築方法を反映する。 このビューは一般に UML コンポーネント図またはクラス図です。

物理ビュー

物理ビューは、システム ソフトウェアと物理ハードウェア間のマッピングを記述し、システムのコンポーネントが計算可能な物理ノードのグループに展開される方法を示しています。

プロセス ビュー

プロセス ビューは、システム ソフトウェア コンポーネント間の通信シーケンスおよびデータの入出力を記述し、システムの機能フローおよびデータ フローを反映させます。 このビューは通常、シーケンス図またはフローチャートとして示される。

開発ビュー

開発ビューは、システムモジュールの分割および構成を記述し、内部パッケージの構成設計を洗練するために使用される。 このビューは開発者が使用し、システムの開発および実装プロセスを反映する。

上記の5つのアーキテクチャビューは、ソフトウェアシステムの異なる特徴を異なる視点から表現している。 アーキテクチャの青写真にそれらを組み合わせることにより、全体的なシステムアーキテクチャを非常に明確に記述することができます。

効果的なアーキテクチャ図を作るには？ また、どのような方法でダイアグラムを作成すべきでしょうか。

上記の図は、さまざまな種類の図を説明するために選択したもので、その品質についてはほとんど考慮していません。 私たちは、良いアーキテクチャ図を描くためには、聴衆が誰であるかを知り、伝えたい情報が何であるかを考えなければならないと考えています。 したがって、物理的なビューや論理的なビューを描くこと自体が目的になってはいけないのです。 ダイアグラムは、特定の読者が必要とする情報を正確に伝えるために使用するのが効果的です。 そのとき初めて、それがどのような種類の図であるかを気にすればよいのです。 したがって、図面の品質を判断する最も直接的な基準は、私たちが伝えようとした情報を聴衆が正確に理解できるかどうかである

これは、優れた効果的な建築図が聴衆に説明される必要がないことを意味している。 それだけで言いたいことがすべて表現されているはずです。 さらに、優れたダイアグラムは、一貫した構造を持ち、表現しているデータに正確で、コードに直接対応していなければなりません。

Common Challenges When Depicting Architectural Diagrams

四角は何を表すのか

なぜ円ではなく、四角を使うのか

なぜ、円の代わりに、四角が使われたのか？ 正方形や他の形がランダムに使われると混乱を招く恐れがあります。

点線と実線の意味は？ 矢印の意味は？ 4655>

線や矢印の恣意的な使用は誤解を招く恐れがあります。

ランタイムとコンパイルタイムに矛盾はありますか。 レベルの競合はありますか。

アーキテクチャを構築することは複雑な仕事です。 したがって、アーキテクチャを表現するために 1 つの図だけを使用すると、アーキテクチャに関する特定の側面で混乱しやすくなります。

私の推奨する描画方法

C4 モデルは、アプリケーション、データストア、マイクロサービスなどのコンテナと、コンポーネントやコードを使ってソフトウェア システムの静的構造を表現する。 これらの図は簡単に描くことができ、その重要な要素は明示されています。 しかし、最も重要なことは、それぞれの図の意図する読者や意義を明確に示すことができることです。

次の例は、C4 の公式サイトからのものです。 これをもとに、独自の理解でなんとかソフトウェア・アーキテクチャをうまく表現しています。

System Context Diagram

これはある銀行システムの計画図である。 これは、外部のメインフレームバンキングシステムを使用して、顧客の口座と取引情報にアクセスし、外部の電子メールシステムを通じて顧客に電子メールを送信します。 見てわかるように、この図はシンプルで明快です。 聴衆が理解するために、追加的な説明は必要ありません。 また、構築されるシステム、システムの顧客、およびこのシステムと相互作用する周辺システムが含まれていることもわかります。

Usage

このように単純な図では、どのタイプのシステムを構築するか、そのユーザーは誰か、誰がそれを操作するか、既存の IT 環境にどう統合されるかを知ることができます。 この図の読者は、開発チームの内部スタッフ、外部の技術スタッフ、または非技術スタッフである可能性があります。

• どのようなシステムを構築するのか、
• それを操作するのは誰か、
• 既存の IT 環境にどのように統合するのか、

図の描き方

この図で、自分のシステムが中央にあり、このシステムと相互作用するユーザーとシステムがその周りに配置されています。 この図の重要な点は、構築するシステムのユーザーと上位の依存関係を整理して明確に示している点です。 概念的な作業を行った後、この図を描写するのに数分しかかかりません。

Container Diagram

コンテナー図は、前のシステム コンテキスト図におけるシステムを拡張したものです。

前の図では、構築するシステムにはユーザーと周辺システムのほかに、Java Spring MVC をベースに、システムの機能ポータルを提供する Web アプリケーション、Xamarin ベースのモバイル アプリケーションでモバイル クライアント用の機能ポータルが提供されています。 また、JavaベースのAPIアプリケーションがサービスを提供し、ストレージにはMySQLデータベースが使用されます。 矢印はアプリケーション間の相互作用を示します。

この図を見るとき、ボックスの角がシャープか丸いか、矢印が実線か点線かは気にならないでしょう。 矢印の方向さえもあまり注意を引かない。

多くの描画方法があり、そのすべてが枠と線の意味を定義している。 そのため、図を描く側と見る側の双方が、これらの定義を明確に理解する必要がある。 そうして初めて、図の中のすべての情報を理解することができる。

用途

この図の利用者は、内部または外部の開発者または O&M 担当者である場合があります。 この図は、次の目的に役立ちます：

• ソフトウェア システムの全体構造を示します。
• 高レベルの技術的意思決定を反映します。
• It tells developers where code programming is required.

How to Depict the Diagram

This diagram uses frames, which may include names, technical choices, responsibilities, and interactions between frames.このダイアグラムでは、フレームを使用します。 外部システムが関与する場合は、境界を定義するのが最善です。

コンポーネント図

コンポーネント図は、コンテナを展開し、その内部モジュールを記述するために使用します。

用途

この図は内部開発者向けで、コードを整理し開発する方法が示されています。 この図は、次の目的に役立ちます：

• システムのコンポーネントまたはサービスを説明します。
• コンポーネント間の関係および依存関係を明確にします。
• ソフトウェア開発タスクが分散して提供できる方法を示すフレームワークを提供します。

Code or Class Diagram

この図は技術サポートの担当者向けのものです。 よくあるタイプの図なので、詳細な説明は省略します。

事例

次の図は、ある内部リアルタイムデータツールのアーキテクチャを示したものです。 アーキテクチャ図は自明であるべきなので、説明はあまり必要ない。 もし明確に理解できなければ、その図は間違いなく十分なものではありません。

優れたアーキテクチャ図を描くための方法論は数多く存在します。 この記事ではC4法を紹介しますが、この手法も常に進化しています。 しかし、どのような描画方法であっても、描画の意図を考慮し、それを聞き手にうまく伝えることができればよいのです。 描画の過程でルールに過度に縛られる必要はないのである。 要するに、図を描き始める前に、自分自身に問いかけてみるのです。 誰のためのものなのか、何のためのものなのか、どうすれば直感的に理解できるようになるのか。

著者について SanhuaはAlibabaの技術専門家です。 Zijing、Pengsheng、Yuleもこの記事に貢献しています。 Ding Yi は以前、ワークフローエンジン R&D に長年従事していましたが、現在は高通貨モバイル インターネット アプリケーションのアーキテクチャと開発に専念しています。 この記事の寄稿者はAlibaba LST Departmentのメンバーです。

あなたはAlibaba Cloudの最新の技術トレンドを知りたくありませんか？ 新しく始まったシリーズ、Tech Showでトップエキスパートの話を聞いてください！

。