Are you fascinated by the various and colorful architectural design diagrams displayed by major manufacturers? When we want to use a few diagrams to introduce the business system, do you not know where to start with the canvas? Don't those who are technical leaders need a picture to describe the system so that all participants in the system can understand it? If there is such confusion, this article will introduce some drawing methodologies to make technical drawings clearer.
Architecture Definition
- The system architecture is the embodiment of the concept, the distribution of the correspondence between the function of the object/information and the form elements, and the definition of the relationship between the elements and the relationship between the elements and the surrounding environment.
- Architecture is an abstract description of the entities in the system and the relationship between entities, and it is a series of decisions;
- Architecture is structure and vision.
In the TOGAF enterprise architecture theory, architecture is a part of top-down refinement from the company's strategic level, from strategy => business architecture => application/data/technical architecture. Of course, the boss's focus is on strategy and business architecture. We need to focus on the layer of application/data/technical architecture for moving bricks.
- Business architecture: Business architects are in charge, also known as business domain experts and industry experts. Business architecture belongs to the top-level design, and its definition and division of business will affect the organizational structure and technical architecture.
- Application architecture: The application architect is responsible for designing the application hierarchy, formulating application specifications, defining interfaces and data interaction protocols, etc. according to the needs of business scenarios. And try to control the complexity of the application at an acceptable level, so as to quickly support business development, while ensuring the availability and maintainability of the system, ensure that the application meets the requirements of non-functional attributes such as performance, security, stability etc.
- Technical architecture: describes which services are required; which technical components are selected to implement technical services; technical services and the interaction between components.
- Data architecture: describes the data model, distribution, data flow, data life cycle, data management and other relationships.
Classification of Architecture Diagrams
The system architecture diagram is to abstractly represent the overall outline of the software system, the interrelationships and constraint boundaries between various components, 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 can allow stakeholders to understand and follow architectural decisions, and architecture information needs to be passed on. Then, the purpose of drawing an architecture diagram is to: solve communication barriers/reach consensus/reduce ambiguity. The more popular ones are 4+1 view and C4 view.
4+1 view
1. Scene view
It is used to describe the relationship between the participants of the system and the functional use cases, reflecting the final requirements and interaction design of the system, usually represented by a use case diagram.
2. Logical view
It is used to describe the component relationship, component constraints and boundaries after the system software function is disassembled, and reflects the overall composition of the system and the process of how the system is constructed. It is usually represented by UML component diagrams and class diagrams.
3. Physical view
It is used to describe the mapping relationship between system software and physical hardware, reflecting how the components of the system are deployed on a set of computer nodes that can be calculated, and is used to guide the deployment and implementation process of the software system.
4. Processing flow view
It is used to describe the communication timing between system software components, data input and output, and reflect the functional flow and data flow of the system, usually represented by sequence diagrams and flow charts.
5. Development view
The development view is used to describe the module division and composition of the system, and to refine the composition design of the internal package, serve the developers, and reflect the system development and implementation process.
The five architectural views represent different features of a software system from different perspectives, and are combined together as an architectural blueprint to describe the system architecture.
C4 view
The following case comes from the official website of C4, and then added some author's understanding.
The C4 model uses containers (applications, data stores, microservices, etc.), components, and code to describe the static structure of a software system. These kinds of pictures are relatively easy to draw, and the main points of drawing pictures are also given, but the most important thing is that, in our opinion, it clearly points out the possible audience and meaning of each picture.
1. System Context Diagram
It is used to describe what the system we want to build is, who the users are, and how it needs to be integrated into the existing IT environment. The audience for this diagram can be internal to the development team, external to technical or non-technical personnel.
2. Container Diagram
The container diagram is an expanded description of the system to be built in the context diagram. The main audience is developers or operation and maintenance personnel inside or outside the team. It is mainly used to describe the overall shape of the software system and reflects high-level technical decisions. And selection, how the responsibilities in the system are distributed, and how the containers interact.
3. Component Diagram
The component diagram is to expand a certain container and describe its internal modules. It is mainly for internal developers to see how to organize and build the code. It describes which components/services the system consists of and the relationship between components. and dependencies, providing a framework for how software development decomposes delivery
How to draw a good architecture diagram
The classification above is a summary of the experience of the predecessors, and the pictures are also taken from the Internet. So are these pictures good? Do we have to follow the gourd painting ladle to draw such pictures? Regardless of whether these diagrams are good or not, we have thought about the classification and functions of these diagrams. In summary, we believe that after clarifying these two points, from the perspective of the audience, a good architecture diagram does not need explanation Yes, it should be self-describing, consistent and accurate enough to echo the code.
view audience
Before drawing a good architecture diagram, you should first clarify its audience, and then think about what information to convey to them. Therefore, don’t draw a physical view just to draw a physical view, and draw a logical view just to draw a logical view. Instead, it should be accurately expressed with pictures according to different audiences and different information to be conveyed. The final pictures may be in such categories. Then, a direct criterion for the quality of the drawn picture is: whether the audience has accurately received the information they want to convey.
View element differentiation
It can be seen that the architectural view is composed of elements such as boxes and lines. It is necessary to use shapes, colors, and line changes to distinguish the meaning of elements and avoid confusion. Architecture is complex work, and using only a single diagram to represent it can easily lead to inexplicable semantic confusion.