Architecture design drawing reference

1. What is an architecture?

Architecture is an abstract description of the relationship between the whole and the part, and describes the relationship between the elements of the system.

2. Architectural formula

Architecture = Elements + Connections + Problem Solving

• Elements: tool objects with specific functions

• Connection: Linking together through the functions, characteristics, and rules of the object

• Problem: demand, contradiction

3. Architecture type

3.1 There are 6 classifications of project system architecture:

3.1.1 Business structure:

Define business strategy, governance, organization, and key business processes.

3.1.2 Data structure:

Describe the organization's logical and physical data assets and the structure of data management resources.

3.1.3 Application architecture:

Description of the structure and interaction between applications.

3.1.4 Technical architecture:

Describe the logical software and hardware capabilities required to support the deployment of business, data, and application services, including IT infrastructure, middleware, networks, communications, processing, and standards.

3.1.5 Security architecture:

Design refers to following the basic principles of security design, under the premise of fully understanding the existing business and application scenarios, and fully understanding the threats faced, the correct deployment and use of security control technologies to meet the security requirements of protecting information assets.

3.1.6 Deployment architecture:

By establishing a communication mechanism between different applications and businesses, the independent parts of the system can be integrated into a whole, so as to improve business efficiency, reduce business costs, and improve data accuracy and process rationality. For this reason, mature and perfect system architecture deployment capability is an important indicator to measure system operation capability.

3.2 Classification of 5 classic software architectures:

3.2.1 Layered architecture:

The software is divided into several horizontal layers, each layer has a clear role and division of labor, and there is no need to know the details of other layers. Communication between layers through interfaces. Although there is no clear agreement on how many layers the software must be divided into, the four-layer structure is the most common: presentation layer, business layer, persistence layer, and database.

Presentation: User interface, responsible for visual and user interaction.
Business: Realize business logic.
Persistence: Provide data. SQL statements are placed in this layer.
Database: Save data

3.2.2 Event-driven architecture:

Software architecture for communication through events.

Event queue: The entrance to receive events.
Distributor (event mediator): Distribute different events to different business logic units.
Event channel: The connection channel between the distributor and the processor.
Event processor ( event processor): Implement business logic, and after processing is completed, an event will be sent to trigger the next operation

3.2.3 Microkernel architecture:

Also known as "plug-in architecture", it means that the core of the software is relatively small, and the main functions and business logic are implemented through plug-ins. The kernel usually contains only the smallest functions that the system runs. Plug-ins are independent of each other, and communication between plug-ins should be reduced to a minimum to avoid interdependence.

3.2.4 Microservice architecture:

It is an upgrade of the service-oriented architecture. Each service is an independent deployment unit. These units are distributed, decoupled from each other, and connected through remote communication protocols (such as REST, SOAP).

The microservice architecture is divided into three implementation modes:

• RESTful API mode: Services are provided through APIs, and cloud services fall into this category
• RESTful application mode: Services are provided through traditional network protocols or application protocols, usually behind a multi-functional application, which is commonly found in enterprises
• Centralized message mode: the use of message broker (message broker) can realize message queue, load balancing, unified log and exception handling. The disadvantage is that there will be a single point of failure, and the message broker may have to be made

3.2.5 Cloud architecture:

It mainly solves the problems of scalability and concurrency, and is the easiest architecture to expand.

This model is mainly divided into two parts: processing unit and virtualized middleware:

• Processing unit: implement business logic
• Virtual middleware: responsible for communication, maintaining sessions, data replication, distributed processing, and deployment of processing units.
  

Virtual middleware contains four components:

• Messaging Grid: Manage user requests and sessions, and when a request comes in, decide which processing unit to assign.
• Data Grid: Copy data to each processing unit, that is, data synchronization. Ensure that a certain processing unit gets the same data.
• Processing Grid: Optional, if a request involves different types of processing units, the middleware is responsible for coordinating the processing units
• Deployment middleware (Deployment Manager): Responsible for the startup and shutdown of the processing unit, monitoring the load and response time, when the load increases, the processing unit is newly started, and when the load decreases, the processing unit is closed.

3.3 C4 model software architecture 4

Architecture composition: system, container, component and code.

Classified by scene 4:

3.3.1 Environmental diagram:

Environment diagram is the beginning of drawing a software system. Draw the system in the middle of a box, and draw some interacting users and other functional systems around the system. The details here are not important, because this is your zoomed-out view, showing an overview of the system. The focus should be on people (roles, roles, roles, etc.) and software systems, not on technology, protocols, and other low-level details. You can show this kind of chart to non-technical people.

• Scope: a single software system.

• Main element: software system in scope.

• Supporting elements: people (for example, users, participants, roles or roles) and software systems (external dependencies) that are directly connected to the software system within the scope. Generally, these other software systems are not within the scope or boundaries of your own software systems, so you do not assume any responsibility or ownership.

• Target audience: Everyone inside and outside the software development team, including technical and non-technical personnel.
  

3.3.2 Container diagram:

After understanding how the system adapts to the entire IT environment, the next really useful step is to use the "container diagram" to enlarge the system boundary. "Containers" are similar to server-side web applications, single page applications, desktop applications, mobile applications, database architectures, file systems, etc. Essentially, a container is a separately runable/deployable unit (for example, a separate process space) to execute code or store data.

The container diagram shows the high-level structure of the software architecture and how to allocate responsibilities within it. It also shows the main technology choices and communication methods between containers. This is a simple, technology-focused high-level chart that is very useful for software developers and support/operations staff alike.

• Scope: a single software system.

• Main element: the container in the software system within the scope.

• Supporting elements: personnel and software systems are directly connected to the container.

• Target audience: technical personnel inside and outside the software development team; including software architects, developers, and operations/support personnel.

Note: This figure does not illustrate deployment scenarios, clustering, replication, failover, etc.

3.3.3 Component diagram

Next, you can zoom in and break down each container to identify the main structural components and their interactions.

The component diagram shows how the container is composed of multiple "components", what each component is, their responsibilities, and technical/implementation details.

• Scope: a single container.

• Main element: the components in the container within the scope.

• Supporting elements: the container (within the software system in scope) and the personnel and software system directly connected to the component.

• Target audience: software architects and developers.
  

3.3.4 Code diagram:

Finally, you can zoom in on each component to show how to implement it as code. Use UML class diagrams, entity relationship diagrams or similar diagrams.

This is an optional level of detail, which can usually be obtained on demand from tools such as IDEs. Ideally, this diagram will be automatically generated using tools (for example, IDE or UML modeling tools), and you should consider displaying only those attributes and methods that allow you to tell the story you want to tell. Except for the most important or complex components, this level of detail is not recommended.

• Scope: a single component.

• Main elements: code elements within the components within the scope (for example, classes, interfaces, objects, functions, database tables, etc.).

• Target audience: software architects and developers.
  

3.4 "4+1" view model software architecture 4 types

• Logical View, the object model of the design (when using object-oriented design methods).
• The Process View captures the concurrency and synchronization characteristics of the design.
• The Physical View describes the mapping of software to hardware and reflects the distributed characteristics.
• The Development View describes the static organization structure of the software in the development environment.
  

4. The role of architecture diagrams

Solve communication barriers
Reach consensus
Reduce ambiguity
Quick understanding