When we want to use one or a few diagrams to describe our system is not often experience the following:
- Against the canvas unable to start, deleted again?
- How to describe a picture of my system, and make the product, operators, developers are slow connection?
- Drew half of the chart is not clear who is the audience?
- Figure drawn in the end product is a functional diagram or chart showing yet another technology or smorgasbord?
- Box on the chart a little less mean little box add to the mix?
- How to draw layout are not satisfied ......
If you have the same confusion, this article will introduce one kind of drawing methodology to allow a clearer view of the architecture.
First clarify some basic concepts
1. What is architecture?
Architecture is an abstract description of the relationship between the entities in the system and carried out by the entity, is a series of decisions.
Architecture is the structure and vision.
The system architecture is the embodiment of the concept, is made to the corresponding allocation between the case where the object / function and form element information is to define the relationship between the elements and relationships between elements made with the surrounding environment.
Good architecture is a complex task, but also a big topic herein, this will not do deeply. With the later framework, we need to make stakeholders understand, follow the relevant decisions.
2. What is the architecture diagram?
System Architecture for an abstract showing the relationship between the overall profile of the system software and an overall view of the various components and constraints deployment direction of the evolution of the physical boundaries of the system and software, and the software system.
3, the role of architecture map
A picture is worth a thousand words. To make stakeholders understand and follow architectural decisions, we need to pass out information architecture. Chart is a good carrier. So, easel composition in order to:
- Solve communication barriers
- Consensus
- Reduce ambiguity
4, Chart Category
Collected a lot of information, there are a lot of classification, there is a more popular view is 4 + 1, respectively scene view, logical view, physical view, the process flow view and development view.
★ scene view
Participants and scene view for describing the function of the system, the system reflects the final demand and interactive design, generally indicated by the relationship between a view of the embodiment of Fig.
Logical View ★
Logical view for describing the relationship between the components after dismantling the system software functionality, assembly and boundary constraints, the process of how the system to reflect the overall composition of the system construction, typically represented by a UML class diagram of the components and FIG.
★ physical view
Physical view used to describe the mapping between the physical system software to hardware components of the system is reflected in how to deploy to a set of nodes may be computers, guidance for deploying software system implementation process.
★ processing flow view
处理流程视图用于描述系统软件组件之间的通信时序，数据的输入输出，反映系统的功能流程与数据流程,通常由时序图和流程图表示。
★ 开发视图
开发视图用于描述系统的模块划分和组成，以及细化到内部包的组成设计，服务于开发人员，反映系统开发实施过程。
以上 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)
组件图是把某个容器进行展开，描述其内部的模块。
★ 用途
This figure is mainly for internal developers to read, how to do code and build the organization. Its use are:
- Which describes the system of component / service composition
- Clarify the relationships and dependencies between components
- Software development provides the framework for how to decompose delivery
4, FIG class (Code / Class Diagram)
It is clear that this figure is for technical personnel to see, more common, not described in detail.
Case Studies
Here is a schematic diagram of a real-time data tools inside. As Chart should be a self-describing, not much to do here to explain. If there do not understand, and it is certainly not good enough yet painted.
Chart may draw a good many methodologies, This part describes the C4 this method, theory C4 is also evolving. In either drawing methodology, drawing us back to the original intention, better communication, we are in the process of painting it need not be limited by the old rules. In short, like a good painting before: drawing to whom, what to see, do not explain how to understand it.
Added: drawing tools Keynote, Xmind, EdrawMax, Visio, OmniGraffle, Process On ......
This paper addresses the physical view Download: Win (http://t.cn/EXAGBDW), Mac (http://t.cn/EXAqtxI)