How to draw an excellent architecture diagram

 At work , When we want to describe our system with one or more diagrams , Do you often encounter the following situations ：
 I can't handle the canvas 、 Delete and come again ？
 Describe my system with a picture , And let the product 、 operating 、 Development can be understood ？
 It's not clear who the audience is after drawing half of the picture ？
 Is the drawing a product diagram, a function diagram, a technical diagram or a hodgepodge ？
 There are a few frames in the picture. Do you want to add some frames ？
 Not satisfied with the layout ……

 If there is the same confusion , This paper will introduce a methodology of drawing , To make the architecture clearer .

Clear up some basic concepts first

1. What is architecture

Architecture is an abstract description of entities in a system and their relationships , It's a series of decisions .
Architecture is structure and vision .
System architecture is the embodiment of concept , It's the right thing / Distribution of correspondence between the function of information and formal elements , It is the definition of the relationship between elements and the relationship between elements and their surrounding environment .

Building a good architecture is a complex task , It's also a big topic , This article will not go deep . With architecture , It needs to be understood by stakeholders 、 Follow relevant decisions .

2. What is architecture diagram

System architecture diagram is an abstract representation of the overall outline of a software system and the relationship and constraint boundary between various components , And the overall view of physical deployment and evolution direction of software system .

3. The role of Architecture

A picture is worth a thousand words . Let stakeholders understand 、 Follow Architecture Decisions , We need to transfer the architecture information . Architecture diagram is a good carrier . that , Easel composition is for ：
Address communication barriers
Reach a consensus
Reduce ambiguity

4. Schema classification
   Collected a lot of information , There are many categories , One of the more popular ones is 4+1 View , Scene view 、 Logical view 、 Physical view 、 Process view and development view .

   Scene view
   
   The scenario view is used to describe the relationship between the actors of the system and the functional use cases , Reflect the final requirements and interaction design of the system , Usually represented by use case diagrams .

   Logical view
   
   The logic view is used to describe the component relationship after the system software function is disassembled , Component constraints and boundaries , Reflect the overall composition and system of the system The process of how to build unity , Usually by UML Component diagram and class diagram of .

   Physical view
   
   Physical view is used to describe the mapping relationship between system software and physical hardware , Reflects how the components of the system are deployed to a set of On the computing machine node , Used to guide the deployment and implementation process of software system .

   Process view
   
   The processing flow view is used to describe the communication sequence between system software components , Input and output of data , Reflect the functional process of the system And data flow , Usually represented by sequence diagram and flow chart .

   Development view
   
   Development view is used to describe the module division and composition of the system , And detailed to the composition design of the internal package , Serving developers , Reflect the implementation process of system development .

above 5 Different architecture views represent different characteristics of a software system from different perspectives , Combine to describe the system architecture as an architectural blueprint .

What kind of architecture is a good one

The above classification is a summary of previous experience , The pictures are also taken from the Internet , How are these pictures ？ Are we going to draw some pictures like this ？

Don't worry about the pictures first, OK , Through the classification and function of these graphs , Think about it , Sum up , We think , Before drawing a good architecture , First of all, the audience should be clear , Think about what message to send them , therefore , Don't draw a physical view to draw a physical view , To draw a logical view, draw a logical view , It should be based on different audiences , Different messages , Express it accurately with pictures , The last picture is probably in some of these categories . that , One of the direct criteria for a good drawing is ： Does the audience receive the information they want to convey accurately .

After making these two points clear , From the perspective of the audience , A good architecture chart needs no explanation , It should be self describing , And be consistent and accurate enough , Be able to respond to the code .
Common problems in easel composition

1. What does a box represent ？

Why a box, not a circle , Does it have any special meaning ？ Random use of boxes or other shapes can cause confusion .

2. Dotted line 、 What do solid lines mean ？ What does arrow mean ？ What does color mean ？
   

Using lines or arrows at will may cause misunderstanding .

3. Runtime and compile time conflicts ？ conflictat different levels ？

Architecture is a complex task , Using only a single diagram to represent the architecture can easily cause inexplicable semantic confusion

Recommended drawing methods

C4 Model use container （ Applications 、 data storage 、 Microservices, etc ）、 Components and code to describe the static structure of a software system . These kinds of pictures are easy to draw , The key points of drawing are also given , But the key is , We think , It clearly points out the possible audience and significance of each map .

The following cases are from C4 Official website , And then added some of our understanding , Let's see how to better express the software architecture

1. Context map (System Context Diagram)
   
   This is an imaginary Internet banking system to be built , It uses an external mainframe banking system to access customer accounts 、 Transaction information , Email customers via external email system . You can see , It's simple 、 Clear , I believe there is no need to explain , You can see it , It contains the system itself that needs to be built , Customers of the system , Peripheral systems that interact with this system .

purpose :
Such a simple diagram , You can tell us , What is the system to build ; Who are its users , Who will use it , How does it fit into the existing IT Environmental Science . The audience of this diagram can be the internal staff of the development team 、 External technical or non-technical personnel . namely ：

What is the system built
Who will use it
How to integrate the existing IT Environmental Science

How to draw
In the middle is your own system , It's surrounded by users and other systems that interact with it . The key to this diagram is to sort out the users and high-level dependence of the system to be built , It's sorted out. It's just a few minutes .

2. Vessel diagram (Container Diagram)
   
   The container diagram is an expansion of the system to be built in the context diagram .
   Above picture , In addition to users and peripheral systems , The system to be built includes a java\spring mvc Of web Application provides the function entrance of the system , be based on xamarin Mobile phone with architecture app Provide function access of mobile terminal , One is based on java Of api Application providing service , One mysql Database for storage , The interaction between applications is indicated on the arrow line .

When I look at this picture , Don't pay attention to the right angle box or rounded box in the figure , Don't focus on solid or dashed arrows , Even the direction of the arrow did not attract much attention .

We have many ways of drawing , All to the box 、 The meaning of the line is defined , This requires that the people who draw and the people who look at the pictures clearly understand these definitions , To read the whole picture , And the reality is , This is often a very high requirement , therefore , A lot of pictures only have a general meaning .

purpose :
The audience of this diagram can be developers inside or outside the team , It can also be the operation and maintenance personnel . Use can be listed as ：
Shows the overall shape of the software system
Reflects high-level technology decision-making
How responsibilities are distributed in the system , How containers interact with each other
Tell developers where to write code

How to draw
Represented by a block diagram , Internal may include name 、 Technology selection 、 duty , And the interaction between these diagrams , If external system is involved , It's better to define the boundary .

3. Component diagram (Component Diagram)

Component diagram is to expand a container , Describe the internal modules .

purpose :
This diagram is mainly for internal developers , How to organize and build code . Its uses are ：
Describes the components of the system / Service composition
Clarify the relationship and dependency between components
It provides a framework for software development to decompose delivery

4. Class diagram (Code/Class Diagram)

This picture is obviously for the technicians , More common , I won't explain it in detail .

In short , Think before you draw ： Who can I show the picture to , What are you look at? , How to understand without explanation .