1. Introduction

Are you deeply attracted by the colorful and colorful architecture design drawings displayed by big factories? When we want to introduce the business system with a few pictures, do we not know where to start on the canvas? As a technical bearer, do they need a map to describe the system, so that each party can see it clearly? If there is such confusion, this article will introduce some drawing methodology to make the technical drawings clearer.

2. Definition of architecture

  • System architecture is the embodiment of the concept, the distribution of the corresponding situation between the function and formal elements of object/information, and the definition of the relationship between elements and the relationship between elements and the surrounding environment.
  • Architecture is the abstract description of the entities in the system and the relationships between them. It is a series of decisions.
  • Architecture is structure and vision.

In TOGAF enterprise architecture theory, architecture is a part of top-down refinement from the strategic level of the company, from strategy => business architecture => application/data/technology architecture. Of course, the boss focuses on strategy and business architecture, so we need to focus on the application/data/technology architecture layer.

  • Business architecture: Business architects are responsible for business architecture, which can also be called business domain experts or industry experts. Business architecture belongs to the top-level design, and its definition and division of business will affect organizational architecture and technical architecture.

  • Application architecture: An application architect is responsible for designing the application hierarchy, formulating application specifications, and defining interfaces and data interaction protocols based on the requirements of business scenarios. In addition, the complexity of applications should be controlled at an acceptable level. In this way, applications can meet the requirements of non-functional attributes such as performance, security, and stability while ensuring the availability and maintainability of the system while rapidly supporting service development.

  • Technical architecture: describes what services are needed; Which technical components are selected to implement technical services; Technical services and interactions between components;

  • Data architecture: describes data model, distribution, data flow, data life cycle, data management and other relations;

3. Classification of architecture diagrams

The system architecture diagram is to abstractly represent the overall outline of the software system and the relationship between each component and constraint boundary, as well as the overall view of the physical deployment of the software system and the evolution direction of the software system. A good architecture diagram enables stakeholders to understand and follow architectural decisions, which require architectural information to be communicated. So, easel composition is to: solve communication barriers/reach consensus/reduce ambiguity. Popular are the 4+1 view and the C4 view.

3.1 4 + 1 views

3.1.1 Scenario View

It is used to describe the relationship between the participants and functional use cases of the system, reflecting the final requirements and interaction design of the system, usually represented by use case diagrams;

3.1.2 Logical View

It is used to describe the component relations, component constraints and boundaries after the disassembly of system software functions, reflecting the overall composition of the system and the process of how the system is constructed. It is usually represented by the component diagram and class diagram of UML.

3.1.3 Physical View

It describes the mapping between system software and physical hardware. It describes how system components are deployed on a group of computable machine nodes and guides the deployment and implementation of the software system.

3.1.4 Process View

It is used to describe the communication sequence between system software components, the input and output of data, and reflect the functional flow and data flow of the system, usually represented by sequence diagrams and flow charts.

3.1.5 Development View

The development view is used to describe the module division and composition of the system, as well as the composition design of the internal package. It serves the developers and reflects the implementation process of the system development.

The five architectural views represent different characteristics of a software system from different perspectives and are combined as an architectural blueprint to describe the system architecture.

3.2 C4 view

The following case comes from C4 official website, and then adds some of the author’s understanding.

The C4 model uses containers (applications, data stores, microservices, and so on), components, and code to describe the static structure of a software system. These diagrams are relatively easy to draw and give the gist of the drawing, but most importantly, we think, they clearly indicate the likely audience and meaning of each diagram.

3.2.1 System Context Diagram

Describe what system we are building, who the users are, and how we need to fit into our existing IT environment. The audience for this diagram can be inside the development team, outside the technical or non-technical people.

3.2.2 Container Diagram

Container figure is to turn the context diagram for system made a description of the construction of the main target audience is internal or external developer or team operations staff, mainly used to describe the software system of the whole form, embodies the high level of technical decision-making and selection, the distribution of the system of responsibility is how to, how the interaction between the container.

3.2.3 Component Diagram

Component diagram is to expand a container, describe its internal modules, mainly for the internal developers to see how to do the organization and construction of code, describes the system by which components/services, the relationship between components and dependencies, for software development how to decompose delivery provides a framework.

4. How to draw a good architecture diagram

The classification above is the previous experience summary, the picture is also picked from the Internet, so these pictures are good? Are we going to draw some pictures like this? To leave the first figure is good, we through the classification of these graphs and action, thinking and summary, we believe that after taking these two points clearly, from the audience’s point of view, a good architecture diagram is not need to explain, it should be a self-describing, and should have enough accuracy, consistency and can photograph echo with the code.

4.1 Audience of the view

Before drawing a good architecture diagram, first should clear its audience, and wanted to know what message on them, so, don’t in order to paint a physical view to physical view, in order to draw a logical view to draw logical view, and should, according to a different audience, which transmit information with figure accurately express, The final picture might be in some of these categories. A direct criterion for a good picture, then, is whether the intended message is received accurately by the audience.

4.2 Element differentiation of views

As you can see, the architectural view is made up of elements like boxes and lines. Use shapes, colors, and line variations to distinguish the meaning of elements and avoid confusion. Architecture is a complex undertaking, and using a single diagram to represent it can easily lead to unaccountable semantic confusion.

Let’s draw a good architecture diagram together!

The resources

  • c4model.com/
  • Software Architecture for Programmers
  • Why do YOU need a software architecture diagram