我々は我々のシステムを記述するために1つまたは少数のダイアグラムを使用したい場合は、多くの場合、以下のことを経験していません。
- 起動できないキャンバスに反して、再び削除されましたか？
- どのように私のシステムの写真を説明し、製品、事業者、開発者は低速接続されていることを確認するには？
- チャートのドリューの半分は観客が誰であるかは明らかではないでしょうか？
- 最終生成物に描かれた図はさらに別の技術やバイキングを示す機能ブロック図又はフローチャートでありますか？
- 少しチャート上のボックスには、小さな箱がミックスに追加する意味ですか？
- どのようにレイアウトを描画するためには満足していない......
あなたは同じ混乱を持っている場合は、この記事では、アーキテクチャの明確なビューを可能にするための方法論を描くの種類を紹介します。
まず、いくつかの基本的な概念を明確に
1.アーキテクチャとは何ですか？
アーキテクチャは、システム内のエンティティ間の関係の抽象的な記述であると、エンティティによって実行される、一連の決定です。
アーキテクチャは、構造とビジョンです。
システムアーキテクチャは、概念の実施形態は、オブジェクト/関数とフォーム要素情報は、周囲の環境で作られた要素の間の要素との関係の間の関係を定義することである場合と対応する割り当てになるです。
良いアーキテクチャは複雑な作業ですが、また大きな話題は、ここで、これは深く行うことはありません。後でフレームワークで、我々は、利害関係者が理解させる関連する決定を実行する必要があります。
2.アーキテクチャ図とは何ですか？
システムソフトウェアおよびシステムとソフトウェア、およびソフトウェアシステムの物理的な境界の進化のさまざまなコンポーネントや制約の展開方向の全体図の全体的な形状との関係を示す抽象ためのシステムアーキテクチャ。
3、建築マップの役割
百聞は一見にしかずです。利害関係者が理解させると建築の決定に従うために、我々は、情報アーキテクチャを渡す必要があります。チャートは良いキャリアです。だから、順番にイーゼル組成：
- コミュニケーションの障壁を解決
- コンセンサス
- あいまいさを軽減
4、チャートカテゴリ
多くの情報を収集し、分類がたくさんあり、より人気のビューがありますシーンビュー、論理ビュー、物理ビュー、プロセスフロービューと展開図をそれぞれ、4 + 1です。
★シーンビュー
参加者とシステムの機能を説明するためのシーンビュー、システムは、一般に、図1の実施形態の図との関係で示され、最終需要とインタラクティブデザインを反映しています。
論理ビュー★
典型的には、構成要素と、図のUMLクラス図で示されるシステムのソフトウェア機能、アセンブリおよび境界制約は、システムは、システム構成の全体的な組成を反映する方法の工程を、解体した後、コンポーネント間の関係を説明するための論理ビュー。
★物理ビュー
システムのハードウェアコンポーネントに物理的なシステム・ソフトウェアとの間のマッピングを記述するために使用される物理的なビューは、ノードの集合への展開方法に反映されているコンピュータ、ソフトウェアシステムの実装プロセスを展開するための指針とすることができます。
★処理フロービュー
处理流程视图用于描述系统软件组件之间的通信时序，数据的输入输出，反映系统的功能流程与数据流程,通常由时序图和流程图表示。
★ 开发视图
开发视图用于描述系统的模块划分和组成，以及细化到内部包的组成设计，服务于开发人员，反映系统开发实施过程。
以上 5 种架构视图从不同角度表示一个软件系统的不同特征，组合到一起作为架构蓝图描述系统架构。
怎样的架构图是好的架构图
上面的分类是前人的经验总结，图也是从网上摘来的，那么这些图画的好不好呢？是不是我们要依葫芦画瓢去画这样一些图？
先不去管这些图好不好，我们通过对这些图的分类以及作用，思考了一下，总结下来，我们认为，在画出一个好的架构图之前， 首先应该要明确其受众，再想清楚要给他们传递什么信息 ，所以，不要为了画一个物理视图去画物理视图，为了画一个逻辑视图去画逻辑视图，而应该根据受众的不同，传递的信息的不同，用图准确地表达出来，最后的图可能就是在这样一些分类里。那么，画出的图好不好的一个直接标准就是：受众有没有准确接收到想传递的信息。
明确这两点之后，从受众角度来说，一个好的架构图是不需要解释的，它应该是自描述的，并且要具备一致性和足够的准确性，能够与代码相呼应。
画架构图遇到的常见问题
1、方框代表什么？
为什么适用方框而不是圆形，它有什么特殊的含义吗？随意使用方框或者其它形状可能会引起混淆。
2、虚线、实线什么意思？箭头什么意思？颜色什么意思？
随意使用线条或者箭头可能会引起误会。
3、运行时与编译时冲突？层级冲突？
架构是一项复杂的工作，只使用单个图表来表示架构很容易造成莫名其妙的语义混乱。
本文推荐的画图方法
C4 模型使用容器（应用程序、数据存储、微服务等）、组件和代码来描述一个软件系统的静态结构。这几种图比较容易画，也给出了画图要点，但最关键的是，我们认为，它明确指出了每种图可能的受众以及意义。
下面的案例来自C4官网，然后加上了一些我们的理解，来看看如何更好的表达软件架构
1、语境图(System Context Diagram)
这是一个想象的待建设的互联网银行系统，它使用外部的大型机银行系统存取客户账户、交易信息，通过外部电邮系统给客户发邮件。可以看到，非常简单、清晰，相信不需要解释，都看的明白，里面包含了需要建设的系统本身，系统的客户，和这个系统有交互的周边系统。
★ 用途
这样一个简单的图，可以告诉我们，要构建的系统是什么；它的用户是谁，谁会用它，它要如何融入已有的IT环境。这个图的受众可以是开发团队的内部人员、外部的技术或非技术人员。即：
- 构建的系统是什么
- 谁会用它
- 如何融入已有的IT环境
★ 怎么画
中间是自己的系统，周围是用户和其它与之相互作用的系统。这个图的关键就是梳理清楚待建设系统的用户和高层次的依赖，梳理清楚了画下来只需要几分钟时间。
2、容器图(Container Diagram)
容器图是把语境图里待建设的系统做了一个展开。
上图中，除了用户和外围系统，要建设的系统包括一个基于javaspring mvc的web应用提供系统的功能入口，基于xamarin架构的手机app提供手机端的功能入口，一个基于java的api应用提供服务，一个mysql数据库用于存储，各个应用之间的交互都在箭头线上写明了。
看这张图的时候，不会去关注到图中是直角方框还是圆角方框，不会关注是实线箭头还是虚线箭头，甚至箭头的指向也没有引起太多注意。
我们有许多的画图方式，都对框、线的含义做了定义，这就需要画图的人和看图的人都清晰的理解这些定义，才能读全图里的信息，而现实是，这往往是非常高的一个要求，所以，很多图只能看个大概的含义。
★ 用途
这个图的受众可以是团队内部或外部的开发人员，也可以是运维人员。用途可以罗列为：
- 展现了软件系统的整体形态
- 体现了高层次的技术决策
- 系统中的职责是如何分布的，容器间的是如何交互的
- 告诉开发者在哪里写代码
★ 怎么画
用一个框图来表示，内部可能包括名称、技术选择、职责，以及这些框图之间的交互，如果涉及外部系统，最好明确边界。
3、组件图(Component Diagram)
组件图是把某个容器进行展开，描述其内部的模块。
★ 用途
この図は、主に内部の開発者がコードを実行する方法を、読み、組織を構築するためのものです。その使用は、次のとおりです。
- どのコンポーネント/サービス構成のシステムを説明
- コンポーネント間の関係と依存関係を明確化
- ソフトウェア開発は、配信を分解する方法のためのフレームワークを提供します
4、図クラス（コード/クラス図）
技術者が詳細に説明されていない、より一般的な、見てのために、この数字があることは明らかです。
ケーススタディ
ここでは内部のリアルタイム・データ・ツールの概略図です。チャートのように説明するためにここに行うことが自己記述、あまりないはずです。そこに理解していない場合、それは確かに十分ではまだ描かれていません。
良い多くの方法論を引き出すことができるチャートは、この部分はC4、この方法は、理論C4も進化して説明します。描画方法のいずれかで、元の意図、より良いコミュニケーションに私たちを描く、我々は古いルールによって限定される必要はない、それを塗装する工程です。前に良い絵のような、要するに：誰に描画するか、何を参照するには、それを理解する方法については説明しません。
追加：描画ツール基調講演、Xmind、EdrawMax、Visioの、OmniGraffleは、上のプロセス......
本論文では、物理的なビューダウンロードに対処します。ウィン（http://t.cn/EXAGBDW）、マック（http://t.cn/EXAqtxI）