Color matching of architecture diagram

One 、 brief introduction

A business architecture diagram is a functional description of a project . It is aimed at ordinary users or top management , Different business architecture diagrams are required for different users , There must be different granularity . It is the task of the drafter to let users clearly understand the business of this project , If you can't satisfy the user , That means the painting is not good enough . So drawing is a process of continuous improvement , No final version .

Two 、 drawing

1、 Appearance requirements

The business architecture diagram describes the functions of the project , But appearance is also important , Good appearance gives users a pleasant feeling .

   ① The first sight of the architecture diagram for readers , Should leave a good impression on the reader , In terms of color matching , The color is not more than 5 individual , Color matching should be differentiated , Different levels 、 Different types need different colors , But you can't jump too much , On the whole, the color style should be consistent , The aesthetic design of the drawing should at least conform to the public's aesthetics . The blue series is recommended here , Blue is more in line with IT Hue of boundary . When choosing colors, avoid too bright colors , Also avoid too much color difference . The same color shall be used for modules of the same level or with the same function .

    ② The second sight should be the overall structure , The whole picture is divided into several levels and modules , Whether the architecture diagram can clearly express the relationship between modules ？ The longitudinal ： layered —— The upper layer depends on the lower layer, and the lower layer , The more basic services ; The transverse ： Parallel relationship , Same level .
    ③ Use of wireframe , The meaning of dotted line box and solid line box is different , Whether to use dashed or solid wireframe can more accurately and clearly express the meaning you want to express . Multiple modules , When it can be logically grouped together, you can use the dotted box .
    ④ symmetry ： Pay attention to the beauty of symmetry , Distribute the functional structure as evenly as possible ;

 

2、 Logic requirements

1、 abstract ： Large modules need to be abstracted , Not specific . Here is an example of eating , If I had rice today , milk , noodles , soup , There are two kinds of abstractions ： Eating and drinking . The idea of abstraction is to abstract many concrete things into the same feature . The functions of the innermost layer can be described in detail .

2、 Hierarchy ： The upper and lower levels are hierarchical , The general business architecture diagram includes ： The user login 、 Business description 、 Service support 、 Data support , Superiors depend on subordinates . The left and right are juxtaposed , If a function accompanies the whole business , It can be carried out .

3 、 Local details

1、 Word expression

    Use words accurately , It can make developers or users understand the meaning of the description
    The name should be unified , English names reflect professionalism , Naming should be as short and consistent as possible ;

2、 Is it comprehensive

3、 Module partition granularity

    The details should be abstracted , Abstract out modules , The granularity of the module should be appropriate , Don't be too specific , Not too broad

4、 Module placement and hierarchical relationship

    Modules at the same level should be unified , The particle size should be uniform ;

5、 The distance between figures is moderate , Avoid excessive spacing 、 Too small , Affect beauty .

    size 、 Format ： Pay attention to the same size , use the same pattern ;

Tips：

    The noun expression of the architecture diagram should be in place , such as ： Technical words cannot appear in the business architecture diagram and operation and maintenance architecture diagram . Because readers of different architecture diagrams are different , Make sure your readers can quickly get To what you want to say , This is very important .

    Whether the content expressed in the architecture diagram is comprehensive , Whether it's business , Technology or operation and maintenance architecture diagram, the content to be expressed must be comprehensive , Including the third-party services that the software system depends on .
    About the granularity of module division in the architecture diagram , It must be appropriate , Not too broad , It can't be too fine-grained , To achieve a layer of abstract granularity of specific small function modules .
    Including whether the logic of module placement is accurate , Placement of each module in the architecture diagram , They are all exquisite , Be able to say why this module is here ？ Can you put it there ？ Why? ？ Can answer these questions , I believe your architecture diagram is not a problem .