1 Introduction
Are you deeply attracted by the various and colorful architectural design diagrams displayed by the big factory? When we want to introduce the business system with a few diagrams, do we not know where to start with the canvas? Do the technical leaders need a picture to describe the system so that all parties involved in the system can understand it? If there is such confusion, this article will introduce some drawing methodologies to make technical drawings clearer.
2. Definition of Architecture
- The system architecture is the embodiment of the concept, the assignment of the correspondence between the function of the object/information and the formal element, 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 entities in the system and the relationships between entities, and is a series of decisions;
- Architecture is structure and vision.
In the TOGAF enterprise architecture theory, the architecture is a part of the top-down refinement from the company's strategic level, from strategy => business architecture => application/data/technical architecture, of course, the boss layer focuses on strategy and business architecture, Our need to move bricks focuses on the application/data/technical architecture layer.
- Business Architecture: It is the responsibility of business architects, also known as business domain experts and industry experts. The business architecture belongs to the top-level design, and its definition and division of the business will affect the organizational structure and technical structure;
- 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 to an acceptable level, so as to support the rapid development of the business, 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 realize technical services; technical services and the interaction between components;
- Data Architecture: Describes the relationship between data model, distribution, data flow, data life cycle, data management, etc.;
3. Classification of architecture diagrams
The system architecture diagram is to abstractly represent the overall outline of the software system and 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 allows stakeholders to understand and follow architectural decisions, and it is necessary to communicate architectural information. Well, the purpose of drawing an architecture diagram is to: resolve communication barriers / achieve consensus / reduce ambiguity. The more popular ones are the 4+1 view and the C4 view.
3.1 4+1 View
3.1.1 Scene View
It is used to describe the relationship between the participants of the system and functional use cases, reflecting the final requirements and interaction design of the system, usually represented by a use case diagram;
3.1.2 Logical View
It is used to describe the component relationships, 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, usually represented by UML component diagrams and class diagrams.
3.1.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 to a set of computable machine nodes, and used to guide the deployment and implementation process of the software system.
3.1.4 Process flow 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. It is 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 refined to the internal package, which serves the developers and reflects the system development and implementation process.
The five architectural views represent different characteristics of a software system from different perspectives, and are combined together to describe the system architecture as an architectural blueprint.
3.2 C4 view
The following case comes from the C4 official website, and then adds some of the 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 diagrams are relatively easy to draw, and they also give the main points of drawing, but most importantly, we think, it clearly points out the possible audience and meaning of each diagram.
3.2.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 people inside the development team, technical or non-technical people outside.
3.2.2 Container Diagram
The container diagram is an expanded description of the system to be built in the context diagram. The main audience is the 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.2.3 Component Diagram
The component diagram is to expand a container and describe its internal modules, mainly for internal developers to see how to organize and construct the code, describe which components/services the system consists of, and describe the relationship between components and dependencies, providing a framework for how software development can be broken down and delivered.
4. How to draw a good architecture diagram
The above classification is a summary of the experience of predecessors, and the pictures are also taken from the Internet. So are these pictures good? Are we going to draw such pictures like a gourd? Regardless of whether these diagrams are good or not, we have thought about the classification and functions of these diagrams, and summed up, we believe that after clarifying these two points, from the audience's point of view, a good architecture diagram does not need to be explained. Yes, it should be self-describing, consistent and accurate enough to echo the code.
4.1 Audience of Views
Before drawing a good architecture diagram, you should first clarify its audience, and then figure out what information to convey to them . Therefore, don't draw a physical view to draw a physical view, but draw a logical view to draw a logical view. Instead, it should be accurately expressed with pictures according to the different audiences and the different information conveyed. The final picture may be in such categories. Then, a direct criterion for whether the drawn picture is good or not is whether the audience has accurately received the information they want to convey.
4.2 Element distinction of views
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 to avoid confusion. Architecture is a complex job, and using only a single diagram to represent it can easily lead to inexplicable semantic confusion.
Let's draw a good architecture diagram together!
References
- c4model.com/
- "Software Architecture Must Read for Programmers"
- Why do you need a software architecture diagram
Author: Color of Code
Link: https://juejin.cn/post/7062662600437268493
Source: Rare Earth Nuggets
The copyright belongs to the author. For commercial reprints, please contact the author for authorization, and for non-commercial reprints, please indicate the source.