Architecture is the basic design of a system or structure. It describes the organization, interrelationships, functions, and behavior of the various components of a complex system. Architecture can exist in any field, including software, hardware, architecture, enterprise, etc.

In the software field, architecture usually refers to the high-level structure of a software system, including individual modules, components, and interactions between them. Software architecture is an important stage in the software development process. Its design determines the overall layout and logic of the system, and has an important impact on the maintainability, scalability and performance of the system.

In the hardware field, architecture involves the design of a computer system, including the way components such as processors, memory, storage, buses, etc. are connected and organized.

In the field of architecture, architecture refers to the design and structure of a building, involving the overall layout of the building, material selection, structural arrangement, etc.

Generally speaking, architecture refers to the overall design and organization of a system. It provides the basic framework for the function and performance of the system and determines the relationship and interaction between various parts.

The essence of architecture can be understood as that it consists of three elements: elements, structures and connections. The interrelationship of these three elements forms the architecture of the entire system.

Elements: refer to the basic elements that constitute the system, which can be components, modules, functions, data, etc. They are the building blocks of the system, the basic units for realizing functionality.
Structure: refers to the organization and arrangement of system elements according to certain rules or layout to form an overall structural framework . Structure determines how elements relate to each other and work together.
Connection: refers to the establishment of connections and interactions between various elements so that they can communicate with each other, transfer information and jointly complete the functions of the system .

Based on the above three elements, architecture is to connect system elements according to a specific structure so that they can cooperate and influence each other to achieve the overall functions and goals of the system.

(2) Division of architectural domains in software design

In software design, architecture domain divides the architecture of the entire system into different levels or areas based on different considerations. These architectural domains describe how a system is structured and organized along different dimensions to better understand and design software systems. The following is a brief explanation of each architectural domain:

Business architecture: Business architecture focuses on the business level of the software system, that is, the business needs, business processes and business rules that the system needs to solve. It involves how to translate business requirements into the functions and behaviors of software systems to ensure that the software system can meet business goals and needs.
Data architecture: Data architecture focuses on how data in a software system is organized and managed. It includes defining data models, data flows, data storage and data access methods to ensure that the system can efficiently process and store data and ensure data consistency and security.
Product architecture: Product architecture focuses on the functions and characteristics of the software system and designs the system from the user's perspective. It considers how to organize various functional modules to provide users with a user-friendly, easy-to-understand, and efficient product experience.
Application architecture: Application architecture focuses on the relationships and interactions between different applications in a software system. It involves how to divide a system into multiple modules or subsystems and define the interfaces and communication methods between them.
Technical architecture: Technical architecture focuses on the technical aspects of the software system, including selecting appropriate development languages, development tools, hardware platforms, etc. It involves how to technically implement the requirements of a software system and ensure the reliability, scalability and performance of the system.

By dividing the architecture of the software system into the above different domains, the software design team can better analyze, plan and implement the system, thereby building a powerful, efficient and stable software system.

(3) Architecture diagram design

The necessity of architecture diagram design

How to draw an architecture diagram

In the architecture design process, architecture decomposition is an essential and critical step. How to perform architectural decomposition and where to start? These require a set of process models and process methods for architectural decomposition to guide decomposition.

From the classification of architecture domains: business architecture, data architecture, product architecture, application architecture, and technical architecture, these five domains require architecture decomposition in turn. The decomposition process of each structural domain is an iterative process. From scratch to something, from coarse to fine, from fuzzy to clear, we refine and enrich the structure step by step. The iterative process is a process of negation. With the gradual advancement of decomposition or the evolution of the system's architecture, subsequent decompositions will not only identify new architectural elements, but may also make adjustments to the previously identified architecture. The iterative process of the entire architecture decomposition can be expressed in a very intuitive way by drawing an architecture diagram.

2. Practice business architecture and product architecture design

In the process of business domain decomposition, starting from the system requirements may only get a vague description, but it is indeed a good starting point.

For vague requirements, a reasonable approach is to first clearly list the problem domain and conduct in-depth problem exploration and domain analysis. This can better understand business scenarios and requirements, which will help with subsequent architecture design and functional planning. Here are some actionable steps for business domain decomposition and problem exploration:

Problem exploration: Conduct in-depth communications with relevant stakeholders, including bosses, operations, users, etc., to understand their needs and expectations. Take the initiative to ask questions, clarify needs, and explore the underlying issues and goals.
Scenario analysis: Analyze the business scenarios involved, understand the business processes and related links, and explore various activities and roles in the problem domain.
Requirements gathering: Collect requirements from all parties and organize them into clear requirements documents. During the sorting process, requirements are gradually refined and clarified to ensure that the scope of the problem domain is clear.
Requirement prioritization: Prioritize the collected requirements to ensure that core issues receive focused attention.
Problem domain division: Decompose the problem domain into relevant sub-domains and classify and categorize them from a macro perspective. The problem domain can be described using flow charts, use case diagrams, or other suitable means.
Domain model: Based on the division of the problem domain, create a domain model to represent the entities, attributes and relationships in the problem domain. Domain models help to better understand business scenarios and problems.
Further refinement: For each subdomain, further refine and clarify requirements, and explore possible solutions and business processes.
Communication and confirmation: Communicate and confirm with stakeholders to ensure that they have a consistent understanding of the problem domain and requirements, and provide continuous feedback for optimization.

Through the above steps, you can gradually transform fuzzy requirements into clear problem domains, providing a better foundation for subsequent architecture design and functional planning. Such a decomposition process helps ensure that you don't overlook important business scenarios and requirements in your architectural design.

Finally, a good product architecture diagram should have the following characteristics:

Clear module functional boundaries
Functions are abstracted, standardized, and independent of each other
The functional boundaries of upstream and downstream products are clear, the architecture layering is clear and reasonable, and it has the ability to iteratively optimize

Simple analysis based on the risk control system.

(1) List the problem areas

The problem domain refers to the spatial collection of all problems that your product can solve. Starting from the core needs, putting all the problems that need to be solved currently and that may need to be solved in the future into the scope of the product framework can help your product architecture have higher scalability and have room for iteration and optimization in the future. The problem domain of the risk control system is shown below:

Detailed steps:

Find statements related to product form and product goals in the requirements received, and list questions such as "What will the process of xx be like" and "How should xx be achieved" until these problems are solved and the core can be achieved. Demand direction and business goals.
In the process of searching for these problems to be solved one by one, whether there are other problems that need to be solved first, or other business-related problems that can be solved.
List all the questions according to the level and attach your own preliminary answers to form a preliminary "problem domain" that your product can solve.

(2) Determine product direction

After listing the problem areas, a vague product direction and functional scope can be obtained. The problem domain is very divergent. This step requires returning to the basics and supplementing, expanding and translating the vague requirements into product requirements that can form a closed loop between business model and user experience. Taking risk control system requirements as an example, the product direction is described as follows:

Detailed steps in determining product direction:

Product users: users who need to clarify product positioning and solve the core needs of core users.
Core goal: Think clearly about what the core goal of your product is. If the value of a product is measured by a KPI, what should this KPI be?
Dependent systems: What external systems does your system need to interact with and relate to, and what is the positioning of our system in this large ecosystem?

(3) Draw business processes and matrices

By analyzing business processes and performing vertical decomposition according to functional responsibilities, business functions and business services are identified and classified into corresponding process nodes. Combine business processes and business function points into a business function matrix. This matrix diagram serves as an important input for the subsequent data architecture, product architecture, and technical architecture in the business architecture.

(4) Functional architecture layering

The product framework was born out of business processes, but compared with business processes, it pays more attention to the enumeration of product functions and the demarcation between functional modules. Taking the business function matrix diagram of the business architecture as input, the flow chart is converted into layers based on nodes, and the function points of the nodes are stored in the same layer.

On this basis, modules that obviously belong to the same product range and the same set of product functions are placed at the same level to obtain a basic product framework.

(5) Clarify functional boundaries

A product architecture diagram with front-end and back-end relationships is divided into at least three layers: user perception layer (reaching users in which scenarios and in what ways), functional module layer (which functional modules are used to realize the core functions of the product, and which external platforms Functions include information interaction) and data layer (where product data comes from and where product data is deposited).

After simple layering in the previous step, a preliminary framework has been obtained, but it is inevitable that there will be problems with unclear layering. At this time, the level of the architecture diagram needs to be processed according to two dimensions: the boundaries of different information levels, and the boundaries of modules and modules within the same level.

Handling the Boundaries of Different Information Levels

The hierarchical expression of the architecture diagram is actually the flow relationship between information. There must be a logical relationship between different information levels. Among them, the user perception layer and the data layer are usually simplified as follows (the functional expression of the user end is often logically simple, and the data source issue is not the core function of the own product), while the functional module needs to follow the logic of its own product to combine the functions within the functional module layer. Main modules become new levels.

Handling the boundaries of submodules within the same level

Although there are correlations between each level, the sub-modules within the same level must be independent of each other and have clear boundaries. Split the functions for solving different problems into two sub-modules so that one problem can only be solved on the same layer to avoid the situation where one problem affects the whole body.

(6) Clarify the boundaries between systems

Product boundaries are very important for the development and design of system architecture and cooperation models between businesses. Use different colors to clearly identify the boundaries of the system to which each part belongs in the architecture diagram. Sections that usually belong to one's own team are identified in bright colors. External systems, such as the data layer, are marked in dark color.

(7) Join the information flow

In addition to expressing the core functions of the product, the product architecture diagram should also reflect the path of information flow. The interaction of current-level data forms product functions, and product functions generate new data, thereby promoting the operation of the next-level functions.

If there is only one main user role of the current product, you only need to use arrows to indicate the way information flows between modules. If the current product involves many roles, you need to use lines with different colors to express the information interaction relationship between them and each module.

3. Extract data architecture from domain model

A good ER diagram needs to have the following principles:

The same entity can only appear once in the same ER diagram
First design the local ER diagram, and then combine each local ER diagram to generate the overall ER diagram.

The important output of the data architecture is the data-entity relationship diagram, or ER diagram for short (containing three basic components: entity data objects, relationships, and attributes). Establishing an accurate data model requires starting from the business architecture, conducting domain modeling analysis on the business domain, and gradually extracting the data architecture diagram (ER diagram). Here are a basic steps to build a product data model:

Understand business needs: Starting from the business architecture, gain an in-depth understanding of business needs and scenarios. Communicate with relevant stakeholders to clarify business rules, processes and data objects.
Domain modeling: Use domain modeling technology to transform business requirements into domain models. The domain model describes the entities, attributes, relationships, and business rules in the business domain.
Identify entities and attributes: Identify entities (data objects) and their attributes in the domain model. Entities are data objects that need to be stored in the system, and attributes are the characteristics of entities.
Define relationships: Determine relationships between entities. Relationships describe connections and dependencies between entities. For example, one-to-many, many-to-many, etc. relationships.
Draw ER diagram: Draw ER diagram based on entities, attributes and relationships in the domain model. ER diagrams use graphical symbols to represent entities, attributes, and relationships to visualize the data structure of the system.
Standardization: Standardize the data model to ensure data redundancy is minimized, data consistency and maintainability are ensured.
Validation and Optimization: Work with stakeholders to validate the accuracy and completeness of data models and optimize and adjust based on feedback.
Continuous evolution: As business needs change, the data model needs to continue to evolve and improve. Ensure the consistency and matching between data model and business.

Speaking of domain models, the four-color prototype method can be used to abstract the business model. Before conducting the four-color model analysis, let’s first understand some basic concepts of the four-color model.

The four-color model, as the name suggests, represents four different prototypes through four different colors.

Moment-Interval Archetype Time-scaled archetype: indicates that something happened at a certain moment or within a certain period of time. Indicated in red, abbreviated as MI.

Part-Place-Thing Archetype Participant-Place-Thing Archetype: Represents people or things involved in playing different roles. Use green. The abbreviation is PPT.

Role Archetype Role Archetype: A role is a mode of participation that is performed by a person or organization, place, or object. Use yellow. The abbreviation is Role.

Description Archetype Description Archetype: A resource that represents a data type, which can be used repeatedly by other archetypes and provides behavior for other archetypes. Use blue. The abbreviation is DESC.

Taking the risk control system as an example, the process of domain modeling is as follows:

(1) Key processes

Before business modeling, you first need to sort out the business process. This step has been completed in the business architecture decomposition process. According to the principles of the four-color modeling method, the business process diagram is modified a little. On the original flow chart, add the transactions and roles involved in the process.

(2) Domain model backbone

From the business flow, the Moment-Interval Archetype can be clearly defined. Each node in the process conforms to the definition of MI, that is, things happen within a certain time period.

In the definition process of MI, one method is to define it through noun + verb.

The MI of risk control is: data collection, rule & model setting, risk identification, alarm notification, risk treatment, and risk analysis (MI is represented in red).

After obtaining the backbone, enrich the model so that it can better describe the business concept. Some entity objects need to be added here. Usually the entity objects include: participants, places, things (party/place/thing).

Part-Place-Thing Archetype: business objects, rules, models, abnormal risks, notifications, abnormal events, analysis reports (PPT is represented by green).

The domain model backbone diagram is as follows:

(3) Domain model role

On the basis of the backbone of the domain model, participating roles need to be brought in. Role is represented in yellow. As shown below:

(4) Domain model description

Finally, the description information of the model is added, which covers the specific attributes of the model. This description information has a great impact on subsequent database design. The model description is marked in blue, as shown below:

(5) Extract ER diagram

After the domain model is constructed, on this basis, we have been able to initially grasp the data model of the entire system. Among them, the green Part-Place-Thing Archetype can be used to represent the entity model in the ER diagram. The red Moment-Interval Archetype can be used to represent relationships in ER diagrams. The domain model architecture diagram is refined and the following diagram is obtained:

There is a certain relationship between entity (Entity) and relationship (RelationShip). Generally, there are three kinds of constraint relationships: one-to-one constraint, one-to-many constraint and many-to-many constraint. These binding relationships are expressed in the ER diagram to show the specific relationships between entities, and the ER diagram is finally output. (Considering to ensure the simplicity of ER, the attributes of the model are not drawn here)

4. Monolithic and distributed application architecture

Application architecture is divided into two types: one is a monolithic application architecture and the other is a distributed application architecture.

Monolithic application architecture

Monolithic application architecture is a traditional application architecture model in which the entire application consists of a single application and all functional modules and components are concentrated in a code base. Data is usually stored in a database or storage medium. This architecture is usually smaller-scale applications, suitable for simple business needs and small team development.

Distributed application architecture

Distributed application architecture refers to splitting the system into multiple independent subsystems. These subsystems can be deployed on different servers and communicate and collaborate through interfaces. Each subsystem has its own data storage, and there are usually multiple databases or data storage media.

	advantage	shortcoming
Monolithic application architecture	Simplicity: Since the entire application is in one code base, development and maintenance are relatively simple. Debugging: With a monolithic architecture, debugging and troubleshooting are relatively easy because all code runs in the same process. Performance: For small-scale applications, a monolithic architecture may be more efficient, avoiding cross-system network communication overhead.	Scalability: A monolithic architecture is difficult to expand horizontally. When the application scale increases or the amount of concurrency increases, performance may be limited. Maintainability: As the size of the application increases, the code base becomes large, and maintainability and team collaboration become complex. Fault isolation: In a single application, the failure of one component may affect the stability of the entire application.
Distributed application architecture	Scalability: The distributed architecture supports horizontal expansion, and more servers and resources can be dynamically added according to demand. Fault isolation: Since the system is split into independent subsystems, the failure of one subsystem will not affect the operation of other subsystems. Flexibility: Each subsystem can use different technology stacks, making it easy to choose the most appropriate technology based on business needs.	Complexity: Distributed architecture involves the cooperation of multiple subsystems, and development and maintenance are relatively complex. Consistency: Multiple databases may cause data consistency problems, requiring additional mechanisms to maintain data consistency. Debugging and troubleshooting: In a distributed architecture, you need to pay attention to issues such as network communication and service invocation. Debugging and troubleshooting are relatively complex.

Generally speaking, the monolithic application architecture is suitable for smaller-scale and simple business applications, and development and maintenance are relatively simple. The distributed application architecture is suitable for complex businesses and large-scale systems, and has better scalability and fault isolation, but needs to deal with challenges such as complexity and consistency. Choosing the right architecture based on business needs and scale is key.

(1) Division application

In the architectural domain of product architecture, the boundaries of the internal subsystems of the product are gradually formed by aggregation and layering between modules. By dividing according to the boundaries of subsystems, the subsystem composition of the entire product can be obtained as shown in the final picture of Part 2 (7) above.

The decomposition of application architecture is divided into two dimensions: horizontal and vertical.

Horizontal division

In the aspect of product architecture, according to the principle that modules of the same product range are placed at the same level, the application system is divided into horizontal levels. As long as the product architecture clearly defines the boundaries between systems, it is easy to identify the various subsystems of the entire product.

vertical division

When the application memory has several relatively independent modules, the business logic of each module is relatively different, and the internal composition is relatively complex and large, it is necessary to further segment the subsystems within the application. The principle of segmentation here is to segment the application according to business to ensure that the sub-applications are independent of each other.

For example, in the case of the risk control system, in the application of the risk control engine, there are real-time and offline verification scenarios. Each scene is relatively independent. At this time, these three modules are divided into subsystems: real-time risk control engine subsystem and offline risk control engine subsystem.

(2) Single application

The monolithic application architecture can usually be divided into four layers: data layer (Data Layer), application logic layer (Business Layer), presentation layer (Presentation Layer) and basic common layer (Common Layer).

Each level will be analyzed below:

Data Layer: The data layer is the layer responsible for handling the storage and access of data. It includes a database or other data storage medium for persistent storage of data. In this layer, database objects such as database tables, views, stored procedures, and triggers may be defined to implement data addition, deletion, modification, and query operations. The main responsibility of the data layer is to manage the storage, reading and writing of data to ensure data security and consistency.
Application logic layer (Business Layer): The application logic layer is the layer that handles business logic and rules. In this layer, the business logic of the application is defined and business requirements and rules are processed. It is responsible for processing requests from the presentation layer, calling the data layer to read and write data, and returning the processing results. The application logic layer does not involve specific data storage details, but focuses on processing business logic to ensure that the business functions of the system are executed correctly.
Presentation Layer: The presentation layer is the layer that interacts with users. It includes user interface and user input handling. In this layer, the design and presentation of the user interface is defined, user input requests are received, and passed to the application logic layer for processing. The main responsibility of the presentation layer is to present information to users and accept user operations.
Common Layer: The basic common layer is the layer that provides common functions and tools. It includes some public modules, classes, libraries, etc., used to provide commonly used functions in the system. These functions may be shared by multiple layers, such as logging, authentication and authorization, exception handling, etc. The main responsibility of the basic general layer is to provide encapsulation and reuse of general functions and reduce the duplication and complexity of the system.

The above four levels form the basic components of the monolithic application architecture. Each layer has independent responsibilities and functions, and they work together to achieve the functions and goals of the entire application. This architectural pattern is more common in small-scale and simple business applications, but as the application scale increases and the business complexity increases, it may face challenges such as scalability and maintainability. In this case, a more flexible distributed application architecture may need to be considered.

According to the above method, we obtain the subsystem in the risk control system: the single application architecture of the disposal center system. As shown below:

(3) Distributed applications

The distributed application architecture diagram is essentially the call relationship diagram of all applications within the product in a distributed environment. Applications call each other through services, which is a typical SOA architecture. In the application architecture diagram, the basic platform functions of the RPC framework such as service registration, service governance, and service discovery in the SOA architecture do not need to be reflected in the application architecture.

The focus of the application architecture diagram is to reflect the logical relationships and communication relationships between applications, and to reflect the internal and external relationships of the product. Internal relationships are the calling relationships between applications within the product; external relationships show the calling relationships between the product and external systems. By presenting the internal and external relationships of the application in the application architecture, the product's positioning and impact on the entire business will become clear.

Calling relationship between applications

Among the various subsystems within the product, in order to solve business needs, data relationships are generated through service calls or asynchronous message calls between applications. Through the division of application systems obtained in the product architecture diagram, an integrated architecture diagram of internal applications is formed according to the calling relationships between systems. In the application integration architecture diagram, it is necessary to mark the business meaning in the call link and clearly mark the business relationships between applications.

External system call relationship

Data input, as the source of business data for products, is largely provided by external systems. In the application architecture diagram, external systems are classified according to business attributes and source relationships, and external source systems are incorporated into the entire application architecture. We know that in a computer system, data input and data output are treated as a whole. In addition to the input system in the application architecture, the output system, as part of the entire product, needs to be included in the application architecture diagram.

External system call relationship

Finally, a good application architecture diagram should have the following characteristics:

Clear application boundaries.
The calling relationship between applications is clear.
What goes in must go out, and where there is an input system, there must be an output system.
Clearly present the global relationship of the application.

5. Strategic and tactical principles of technical architecture

Businesses are ever-changing and technologies are constantly emerging. There is no universal technical architecture model that can be applied to all systems. So, how do we ensure that we can achieve a stable and excellent system when doing technical architecture. In the face of these "uncertainty" architectural design issues, here are some design principles from both strategic and tactical levels. The strategic layer provides methods and ideas for technical architecture, which is a top-level design; the tactical layer provides technical practice methods for technical architecture, which is more focused on detailed design.

(1) Strategic level design principles

The design principles at the strategic level can be succinctly summarized into three main principles: the principle of appropriateness, the principle of simplicity and the principle of evolution.

Appropriateness Principle

The principle of appropriateness refers to selecting appropriate technologies and solutions to meet the needs of the system when designing technical architecture. Don’t blindly pursue new or popular technologies, but choose the most suitable technologies and tools based on actual needs and business characteristics. Make informed technology choices considering factors such as system size, performance, reliability, and security.

Simplicity Principle

The principle of simplicity emphasizes maintaining simplicity and understandability in technical architecture design. Avoid over-design and complexity, and keep the architecture simple and intuitive, making it easy to understand, maintain, and optimize. A simple architecture is easier for team members to understand and master, reducing system development and maintenance costs.

Evolutionary Principle

The evolution principle refers to considering the evolution and changes of the system when designing the architecture. System requirements and business environments will continue to change, and the architecture should be flexible and evolvable enough to adapt to future changes and needs. Avoid over-coupling and tight binding, and split the system into independent modules and components so that it can evolve and expand independently.

The design principles of these three strategic layers provide architectural design methods and ideas to help ensure that the system can achieve stable, efficient and excellent performance in uncertain business and technical environments. Proper application of these principles during the architecture design process can ensure the rationality of technical decisions and the long-term success of the system.

(2) Tactical layer design principles

The design principles of the tactical layer can indeed be divided into three important parts: high concurrency principles, high availability principles and business design principles.

High Concurrency Principle

The principle of high concurrency emphasizes that when designing the architecture, the system needs to support high concurrent requests. For large-scale systems or scenarios facing high concurrent access, it is necessary to choose appropriate technology and architectural solutions to ensure that the system can effectively handle a large number of concurrent requests. This may involve the use of distributed architecture, caching technology, asynchronous processing and other means to improve the system's concurrent processing capabilities.

High Availability Principle

The principle of high availability refers to ensuring that the system can maintain availability in the face of failures or unexpected situations. To achieve high availability, you need to choose technologies and architectures with redundancy and fault recovery capabilities. For example, use load balancing and failover technology to ensure that the system can seamlessly switch to other servers when one server fails to maintain service availability.

Business Design Principle

Business design principles emphasize paying close attention to business requirements and business logic in technical architecture design. The architectural design should closely match the business logic to ensure that the system can perform business functions correctly and efficiently. This may involve adopting appropriate design patterns and best practices to achieve system maintainability and scalability.

By following the design principles of these tactical layers, technologies can be selected and used more accurately during the technical architecture design process to ensure that the system meets high concurrency and high availability requirements while closely matching business needs.

(3) Technical architecture diagram

The technical architecture diagram displays the system's technical solutions and technology selection through views. Technical architecture diagrams are divided into two categories: one type, functional requirements technical architecture diagram (logical architecture diagram), which is a diagram depicting how to realize system product functions through technical components. On the other hand, the non-functional requirements technical architecture diagram (physical architecture diagram) is a diagram depicting how to implement system operation through physical deployment.

Logical architecture diagram

The functional requirements technical architecture diagram is based on the product architecture diagram and application architecture diagram. What technologies are needed to implement each function point and what the technology implementation logic is are shown on the technical architecture diagram. Functional requirements technical architecture diagram drawing can be realized according to the idea of "whole-part-whole".

overall

First, the application distribution framework can be obtained according to the application distribution of the application architecture diagram. as follows:

local

On the basis of the overall framework, each local subsystem is expressed in detailed technical implementation. The technical architecture diagram of the subsystem needs to show the technical components used by each subsystem, such as (caching technology, message middleware, process engine, streaming computing framework, etc.). At the same time, how these technical components implement business functions needs to clearly demonstrate the technical implementation logic. The figure below is the technical architecture of the three subsystems of the real-time engine, offline engine, and quasi-real-time engine in the risk control system.

In the real-time engine, RuleEngine (rule engine) is mainly used as a technical feature. Here we focus on RuleEngine. The quasi-real-time engine uses Blink as the technical framework for stream computing and briefly displays the computing logic.

overall

After completing the technical implementation of each subsystem, a final integration is performed to draw an overall system technical architecture diagram. Data interaction between subsystems is realized through technologies such as service interfaces, databases, caches, or message brokers. This will open up the various subsystems and realize the series connection of data and technology in the entire product.

Physical architecture diagram

The physical architecture focuses on the design architecture of basic software and hardware such as network design, cluster design, middleware design, and data storage design. The technical architecture diagram of non-functional requirements focuses on showing how the enterprise system is physically deployed. The physical architecture specifies the physical elements that make up the system, the relationships between the physical elements, and their deployment strategies. The physical architecture reflects the organization of a software system as it runs dynamically. From the physical architecture diagram, we can gain a global understanding of how the entire system operates from traffic access, data transfer, data storage to technical components.

Reference articles and link descriptions

"Five Steps of Architecture Design Practice", Hu Bin, a Cainiao network technology expert, is currently responsible for the construction of the Cainiao risk control system. He once worked in Taobao Technology Department and was responsible for seller platform, merchant operations and other fields. He has many years of development and management experience in the fields of large-scale distributed applications, big data, and architecture. Mainly from this part, Five Steps of Architecture Design Practice (1): Architecture and Architecture Diagram_Architecture_Hu Bin_InfoQ Selected Articles
"A Note on Distributed Computing" (Leslie Lamport) - This paper raises the issue of consistency in distributed systems and introduces the concept of Lamport clocks. This is one of the classic problems in distributed systems and is of great help to the understanding of distributed architecture.
"Microservices: A Definition of This New Architectural Term" (Martin Fowler) - This article written by Martin Fowler defines the concept of microservices architecture. It explains the characteristics, advantages and challenges of microservice architecture, and has an important impact on modern software architecture design.
"No Silver Bullet: Essence and Accidents of Software Engineering" (Frederick P. Brooks Jr.) - This is a classic software engineering paper that points out that there is no single solution to all software engineering problems and the importance of software architecture design. Reflection and practice provide deep insights.
"The Design of Design: Essays from a Computer Scientist" (Frederick P. Brooks Jr.) - This book collects several essays by Frederick P. Brooks Jr., covering topics in software design and architecture, and providing an introduction to design principles. and practice were discussed in depth.
"The Fallacies of Distributed Computing Explained" (Peter Deutsch) - This article introduces common fallacies in distributed computing and has great implications for the design and analysis of distributed systems.
"On the Criteria to Be Used in Decomposing Systems into Modules" (David L. Parnas) - This is a classic modular design paper that proposes the principles and guidelines of modular design and provides information on the design and architectural decomposition of software systems. important guidance.
"The Mythical Man-Month: Essays on Software Engineering" (Frederick P. Brooks Jr.) - This book is a classic in the field of software engineering. It covers many topics such as software project management, architecture and design, and has a profound understanding of software. Architects and designers are very inspired.

Analysis of architectural design prototype diagram from the perspective of risk control system

1. Understanding of architecture and architecture diagrams

(1) The essence of architecture

(2) Division of architectural domains in software design

(3) Architecture diagram design

The necessity of architecture diagram design

How to draw an architecture diagram

2. Practice business architecture and product architecture design

(1) List the problem areas

(2) Determine product direction

(3) Draw business processes and matrices

(4) Functional architecture layering

(5) Clarify functional boundaries

Handling the Boundaries of Different Information Levels

Handling the boundaries of submodules within the same level

(6) Clarify the boundaries between systems

(7) Join the information flow

3. Extract data architecture from domain model

(1) Key processes

(2) Domain model backbone

(3) Domain model role

(4) Domain model description

(5) Extract ER diagram

4. Monolithic and distributed application architecture

(1) Division application

Horizontal division

vertical division

(2) Single application

(3) Distributed applications

Calling relationship between applications

External system call relationship

External system call relationship

5. Strategic and tactical principles of technical architecture

(1) Strategic level design principles

Appropriateness Principle

Simplicity Principle

Evolutionary Principle

(2) Tactical layer design principles

High Concurrency Principle

High Availability Principle

Business Design Principle

(3) Technical architecture diagram

Logical architecture diagram

Physical architecture diagram

Reference articles and link descriptions

Guess you like