Architect Diary - How to Build a New System | JD Cloud Technical Team

I. Introduction

Architecture design can be divided into multiple dimensions such as engineering architecture, business architecture, and deployment architecture according to the implementation process. A good system architecture standard should have the characteristics of scalability, maintainability, reliability, security, and high performance. Although these features are well known to everyone, we are more eager to know the key path to achieve these requirements in order to incorporate these features into the architecture design. Only in this way can we ensure that the system can adapt to future business growth and delivery efficiency. This article will focus on how to carry out engineering architecture design.

Two value first

When there is ambiguity in the plan, it is very important to examine the plan and make a decision from the perspective of product (commercial) value;

Two misunderstandings that technology is prone to fall into:

1. Comers are not rejected : the needs raised by the product manager are all reasonable, and I am responsible for completing them;

2. Technology-driven : This kind of technology implementation is particularly ingenious, allowing product features to adapt to technology implementation;

The above two types of misunderstandings can easily lead to deviations in R&D's understanding of product value, and can easily have a subversive impact on subsequent technical iterations. From the perspective of product (commercial) value, all parties involved in the collaboration can look at issues from an equal perspective. Not only can it be easier to reach a consensus, but it can also better plan for business evolution and technology iteration.

Software is also a product, and when the system is designed, it will also revolve around several production factors such as the market, organization, and resources.

1. The market is the target of our products, which is the foundation of our construction system;

2. Organization is the resource coordination and guarantee mechanism around the product delivery process;

3. Resources are the production materials such as machines, personnel, time, and operations that are invested in products;

Software development is a production and management activity that revolves around the ratio of input to output (ROI). Scalability, maintainability, reliability, security, and high performance are all features of our products, and each feature requires considerable investment to achieve.

1. Fast speed is the most prominent characteristic of a sports car, which sacrifices road condition adaptability, ride comfort and driving safety;

2. The highlight of off-road vehicles is road condition adaptability, which sacrifices speed and comfort;

3. The car has achieved a relative balance between road condition adaptability, ride comfort, driving safety and driving speed, and has become a common means of transportation;

As the saying goes: "The general is on his way, not after the little rabbit", there is always a trade-off. We do not seek to create a perfect complex system, but we can pursue excellence under limited conditions!

Three architecture design

Architectural patterns describe the relationships, responsibilities, and interaction methods among various components in a software system, thereby providing a specification and constraint for software design, thereby improving software production efficiency. It is mainly reflected in the following two aspects:

1. Help developers better organize and design software systems;

2. Promote collaboration and communication between teams, making it easier for team members to understand and divide work;

3.1 Engineering framework

New systems often start with building the basic engineering framework of the project, including engineering constraints such as directory structure, configuration files, and code templates. They are mainly used to standardize project structure, responsibility boundaries, and code style, thereby improving code quality and maintainability. Specifically include the following aspects:

1. Agreed on the dependencies and interaction methods of each module;

2. Standardize the interface interaction protocol;

3. Unified exception coding, capture and processing;

4. Standardize the log printing format;

5. Restricted by other public norms;

The following gives some practical ideas on the most commonly used layered architecture and DDD architecture.

3.1.1 Layered architecture

There are many forms of layered architecture, such as MVC, hexagonal architecture, etc., which gradually evolved with the development of business and technology.

In the early days of the Internet, due to the limitations of factors such as poor computer hardware performance, slow network speed, and high storage costs, the form of Internet products was relatively simple, and only relatively simple products such as simple portal websites and BBS forums could be realized. The technical architecture at that time did not have the concept of layering, and scripting languages such as ASP, JSP, and PHP were mainly used. It was very common to mix and write HTML, JavaScript, CSS, and SQL in these script files. With the development of Internet technology and the online appeal of more complex businesses, the disadvantages of dynamic scripting languages have gradually emerged. Take the JSP scripting language as an example:

1. Complexity : The development and maintenance of JSP scripting language is more complicated, because it needs to deal with the mixing of Java code and HTML code;

2. Security : JSP scripting language is vulnerable to security vulnerabilities such as SQL injection attacks, resulting in system instability or attacks;

3. Scalability : The scalability of the scripting language is relatively limited, because the Java code needs to be written directly in the HTML page, resulting in a unclear system structure;

In order to solve the above problems, various frameworks have emerged, such as Spring, Struts and so on. These frameworks gradually replaced the JSP scripting language, and also proposed the concept of layered architecture. The most typical of these is the MVC (Model, View, and Controller) architectural pattern, whose main purpose is to decouple different parts of the application, making it easier to maintain and expand. The specific implementation is as follows:

1. Separation of concerns : Divide the application into three main parts so that each part can be developed and tested independently, resulting in better separation of concerns;

2. Improve maintainability : because of the separation of concerns at three levels, it is easier to maintain and modify different parts of the application;

3. Improve scalability : display logic and business logic control are separated, making it easier to expand different parts of the application;

In a multi-layer architecture, the view layer usually uses a template-based framework (such as Thymeleaf, Freemarker, Velocity) or a separate technology stack (such as Vue.js, React). The evolution of these technologies can solve more complex problems, such as financial insurance and e-commerce scenarios, but it will also bring some new pain points:

1. The learning curve is relatively steep : because the MVC architecture pattern requires developers to understand and master multiple concepts and technologies, the learning curve is relatively steep;

2. Increased complexity : Since the MVC architecture pattern needs to divide the application into multiple parts, it increases the complexity of the application;

3. Increased development time : more testing and integration work is required, which increases development time;

In order to improve product delivery efficiency and lower technical thresholds, modern R&D work is usually divided into multiple positions, including front-end development, back-end development, quality testing, operation and maintenance guarantee, etc. These positions need to work together to complete product research and development tasks. In order to ensure the orderly collaboration between multiple business lines and multiple positions, and effectively manage and control process risks, there are usually project management positions.

The MVC architecture separates the focus of the entire business implementation, but in more complex large-scale projects, especially in the scenario of multi-person collaboration and multi-service parallelism, the MVC architecture often appears powerless. At this time, it needs to be split at a finer granularity to achieve parallelism of multiple business lines without large task resource conflicts. Of course, different business scenarios will have different split modes. The most common split mode is the multi-layer architecture mode , as shown in the following figure:

Through the horizontal layered architecture, we have realized the division of labor and collaboration in R&D, and all experience constraints are reflected here. In the figure above, the control layer is subdivided twice. It can also be readjusted according to the actual application scenario. For example, whether the web module can rely on the RPC module can be limited in the POM file. In this way, everyone can implement the development work according to the existing project agreement.

Briefly describe the role of each module layering:

1. Data access layer : Decoupling the business logic layer and the data storage layer belongs to the category of the model layer. It interacts with the underlying data sources (MySQL, Hbase, EleasicSearch). Common frameworks include: MyIbatis, Hibernate, etc.;

2. Remote call layer : the RPC layer, a data access layer parallel to the DAO layer, the difference is that it provides access capabilities through third-party interfaces or platform services. The difference from the DAO layer is data ownership and domain transaction control;

3. Transaction management layer : also called general business processing layer, it has the following characteristics:

◦For the upper-level business, the business and technology sharing capabilities are lowered, such as: unified order production capacity for multiple business formats, general distributed transaction consistency solutions, etc.;

◦Rely on the lower layer, combine the capabilities of the DAO layer and the RPC layer, and realize the transaction management of a single business;

◦For simple business systems, the responsibility of the Manager layer can be replaced by the Service layer;

4. Business logic layer : Relatively specific business logic service layer, mainly responsible for the assembly and arrangement of business processes, the real flexibility and scalability are mainly reflected here;

5. Request processing layer : mainly forwarding access control, shaping input parameters, customizing output parameters, etc. Its responsibility is to directly face each terminal or third-party service provider;

6. Open service layer : define the RPC service provided externally. The functional responsibilities are similar to those of the Web layer. Factors such as gateway security control and flow control also need to be considered;

7. Terminal display layer: template rendering and execution display of each terminal, velocity, React, IOS mobile terminal, etc.;

Traditional software design often leads to tight coupling between various components, which makes the code difficult to maintain and expand. The hexagonal architecture pattern is a variant of the layered pattern, which achieves a loosely coupled design by separating business logic from technical details such as frameworks and libraries, making the code easier to maintain and expand. At the same time, the hexagonal architecture pattern can also help developers better implement unit testing and integration testing, thereby improving software quality. This is very useful in various technology-based business scenarios, as shown in the following figure:

3.1.2 DDD architecture

Domain-Driven Design (DDD) is a software development method that focuses on the business domain. By in-depth understanding of business domain knowledge, business logic is encapsulated in the domain model to achieve better code maintainability and maintainability. Scalability and reusability.

DDD belongs to a loose layered architecture, and the responsibilities and functions of each layer are as follows:

1. User interface layer : external input requests such as web requests, rpc requests, and mq messages;

2. Application layer : responsible for orchestration, forwarding, verification, etc., which is different from the service layer in MVC, which stores a large amount of business logic;

3. Domain layer : that is, the model layer, responsible for expressing business concepts, business status and business rules. Contains all complex business knowledge abstractions and rule definitions in this field, including entities, value objects, aggregates (aggregate roots), domain services, domain events, warehousing, factories, etc.;

4. Infrastructure layer : Provide persistence mechanism and other general technical support capabilities for the domain model, such as message communication, general tools, configuration, etc.;

Why is the popularity of DDD unabated all the year round, but in our actual system development process, there are few projects that are fully implemented? In other words, systems with MVC architecture style are very common, but systems with DDD architecture style are rarely seen. This has to go back to DDD itself: it is a software development methodology for solving complex businesses .

If the common CRUD business system is also implemented according to this model, it will increase the complexity of the system. In general, DDD mode is applicable to the following scenarios:

1. Support complex business logic scenarios : When an application needs to process complex business logic, DDD can encapsulate the business logic in the domain model, thereby better reflecting business requirements and business processes, and reducing the complexity of the system architecture;

2. Highly maintainable and scalable scenarios : DDD splits the application into multiple subdomains, and each subdomain has its own domain model, which can better manage business complexity;

3. Scenarios that require rapid iteration and delivery : each subdomain can be independently developed, deployed, and expanded, which enables the team to quickly iterate and deliver applications;

In order to assess the complexity of the business, we need to consider multiple aspects, such as business processes, product rules, data structures, and frequency of demand changes. In general, adopting this architectural model requires careful evaluation, because implementing this development model will face the following challenges:

1. It is necessary to deeply understand the business domain : DDD is a design method centered on the business domain, so it is necessary to deeply understand the knowledge of the business domain in order to design a domain model that meets the business requirements;

2. Cross-departmental collaboration is required : the implementation of DDD requires cross-departmental collaboration, including business personnel, developers, testers, etc., and everyone needs to work together to reach a consensus;

3. High technical difficulty : DDD needs to understand many complex concepts, such as domain events, aggregate roots, domain services, etc., requiring developers to have a certain technical level;

In short, whether it is the team collaboration model, personal technical ability requirements, or the achievement of business consensus, there are great challenges in all aspects. But this does not mean that DDD is useless in ordinary business systems. Its ideas for solving complex problems can still benefit us. Commonly used tool frameworks, such as CQRS framework, event-driven architecture and microservice framework, all have the shadow of DDD design ideas.

Taking the microservice architecture as an example, first look at the following questions:

• How should microservices be designed?

• What is the basis for splitting microservices?

• How are microservices divided?

If microservices are divided too finely, more services will increase the difficulty of operation and management; if they are too coarse, the degree of functional coupling is high, and there are deficiencies in flexibility and scalability. So this is a trickier question.

Determining business and application boundaries is the key to solving the microservice dilemma. DDD solves the problem of business boundaries very well, and it provides a methodology for dividing the scope of business domains.

Microservice is to split an application into multiple subdomains, and each subdomain opens its capabilities to the outside world in the form of microservices. Microservices limit complex business processes and rules within the scope of the domain, that is, implement their own domain models and data storage internally. From the perspective of the application layer, this standardizes and unifies the implementation of domain services, greatly simplifies the code logic, and better manages business complexity.

3.2 Technology selection

In addition to the basic framework, the construction of the engineering architecture also has an important part, which is the selection of various basic middleware, which is what we often call technology selection. Let me tell you about the main points that need to be paid attention to in technology selection based on examples.

3.2.1 Business requirements

Understand business requirements, and clarify system functions, performance, security, and future expansion requirements.

Example : When dividing system modules, some systems will be split into [WEB] + [JSF microservice] two sets of applications for separate deployment, while some systems will only deploy one [WEB] application. What is the standard of judgment in the middle? What is the function of the [JSF microservice] that is disassembled?

Capability reuse : The microservice layer has a more general model design and a stronger ability to reuse multiple business scenarios. In the process of service operation, it can be deployed vertically according to the business;

Resource isolation : Deploy vertically according to business, and optimize network, machine and other hardware resources in a more refined manner. On the other hand, resource isolation between upper-layer WEB applications and lower-layer microservices can also achieve more refined resource allocation.

To sum up: If your service does not require multi-terminal multiplexing and resource operation, there is no need to disassemble the deployment and increase the multiple investment of call links and machine resources. On the contrary, the benefits of service splitting are even greater.

3.2.2 Technical characteristics

Evaluate the characteristics of different technologies, including aspects such as usability, performance, security, scalability, maintainability, etc.

Example : I once encountered a system where the underlying storage layer used db4o (an open source object-oriented database). This middleware has many advantages:

• Direct access to data in the form of objects;

• No database server is needed, only one data file is needed, and the dll size is only more than 300k;

• Data query, easy to operate and powerful, even without using SQL;

But it is still not recommended to use it here, because we are a distributed cluster service, and this database file can only be stored on a single machine, that is, there is a single point of failure problem, which is the most fatal. Sometimes in order to make up for similar defects, you may need to spend more costs. Conversely, if it is used as an embedded database and applied to some single-chip microcomputers, its advantages can be revealed.

3.2.3 Community support

Consider the degree of community support of the technology, including whether there is an active community, whether there are a large number of documents and tutorials, whether there are mature third-party libraries, etc.

Example : In the distributed scheduling framework, tbschedule was open source relatively early, but no one maintained it long after it was open sourced. If it is used lightly in ordinary business and the application layer is well monitored, it should not be a big problem. However, if it is widely used as basic middleware, it is obvious that it urgently needs to be upgraded and optimized in terms of the observability of the scheduling process, the zk reconnection mechanism, and the automatic recovery of scheduling exceptions. But the reality is that the community has already stopped maintaining it, which is a troublesome thing.

3.2.4 Team skills

Choose the right technology based on your team's skill level and avoid overly complex or unfamiliar technologies. This is very important, otherwise the later maintenance cost and iteration efficiency improvement will become a big problem.

Example : The Cobol language is a programming language widely used in the financial industry in the 1970s. It can handle large amounts of data and complex calculations, and has a high degree of reliability and security. Until 2015, it also ran 43% of the world's banking system and 95% of ATMs.

But in March 2023, Japan announced that it plans to convert the entire banking system Cobol to the JAVA language. The reason is that technicians proficient in this ancient language are very scarce, and the Cobol ecosystem cannot keep up with new developments such as machine learning and cloud integration. The maintenance cost and iteration efficiency of the entire system are far lower than the modern JAVA ecosystem.

3.2.5 Cost-effectiveness

Evaluate the cost-effectiveness of different technologies, including development costs, operation and maintenance costs, license fees, etc.

1. If there are mature open source plugins available, we should try to use them instead of reinventing the wheel;

2. For the tasks that other teams have completed, we need to consider whether they can be reused;

Example : Most of the current technology middleware requires the support of JDK8 or above, so when making technology selection, we need to consider the appropriate JDK version. With the release of Spring Boot 3, the default supported JDK version is 17, and JDK8 is no longer supported. For the new system, it seems more appropriate to choose the new version. For the existing system, it is necessary to consider whether the new version upgrade will match the cost of system transformation and the benefits brought by it, instead of pursuing new technologies for granted.

3.2.6 Risk assessment

Assess the risks of different technologies, including technology maturity, security vulnerabilities, dependencies, etc.

Example : Fastjson is an open source JSON parsing library, which can parse JSON-formatted strings, supports serialization of Java Beans into JSON strings, and deserialization from JSON strings to JavaBeans. It has the characteristics of high execution efficiency and wide range of applications. Now, when choosing a technology, you need to be careful. The reason is that in the past two years, it has frequently exposed security vulnerabilities, and the dependent applications need to be updated frequently to fix the vulnerabilities. This is just the appearance, and the deeper reason is the lack of safety assurance, which is a factor that has to be considered when selecting technology.

3.2.7 Summary

When choosing a technical solution, there is no need to be obsessed with the latest and hottest technology. It is advisable to choose the most suitable solution by comprehensively considering multiple factors such as business needs and team skill reserves. Of course, in order to adapt to ever-changing business needs and technology development trends, it is also necessary to have the awareness of timely technical assessment and update.

Four Normative Consensus

The importance of consensus is to ensure consistent communication and understanding among team members. By formulating specifications and processes, duplication of work and errors can be reduced, and conflicts and misunderstandings can be avoided, which is conducive to improving R&D efficiency and quality.

4.1 Data Layering

4.1.1 Object Conversion

In a layered architecture, there are interdependencies and references between layers, and data is passed through parameter objects. In order to ensure the stability of the internal structure of each layer, we need to carry out anti-corrosion design. This is the key to achieving high cohesion and low coupling.

Example : A table in the model layer has 20 fields, and the corresponding PO object has 20 attributes. However, the terminal display layer only needs to display 10 fields. When the request processing layer (Web) obtains data, it is not necessary to pass back the entire PO object. At this time, we can use the DTO object with only these 10 attributes to pass the result to the request processing Layer, so that the server table structure and some sensitive data will not be exposed.

The common method of data anti-corrosion design is to define its own data structure at each layer. The common methods are:

1. VO (View Object): View object, mainly corresponding to the data object displayed on the interface;

2. DTO (Data Transfer Object): data transfer object, mainly used in places where a large number of transfer objects are required, such as remote calls;

3. DO (Domain Object): domain object is a tangible or intangible business entity abstracted from the real world;

4. PO (Persistent Object): Persistent object, which forms a corresponding mapping relationship with the data structure of the persistence layer (usually a database);

In actual development, for the sake of convenience, it is not necessary to define its own data object for each service layer, and it can be handled flexibly according to the actual situation. For example, in some simple business scenarios, you can skip DO layer objects and directly convert PO objects into VO objects.

4.1.2 Object reuse

In a system that has been iterated for a long time, it is easy to encounter a problem, that is, the scope of some objects is out of control, and its typical characteristics are:

1. For an input object, several methods are shared. Adjusting the definition of an attribute value has a wide range of influence and high risk;

2. Use the Map container directly as the input or output object of your service. No one can tell how much content is in the container;

3. In an object definition, there are multiple similar attribute definitions. When new requirements come, in order to reduce the risk, simply define a new one, and so on;

The out-of-control problem of the scope of the object will lead to a significant decrease in the overall stability and iteration efficiency of the system. This problem is usually a slow cumulative process that develops unconsciously. Its disadvantages often erupt when major system adjustments are made.

To solve such problems, we can start from the following aspects:

1. Prevention : Give a clear specification definition when designing the architecture;

2. Discovery : conduct design and code reviews regularly, and correct problems in time after discovering them;

3. Stop loss : If such a system is discovered, micro-refactoring needs to be considered to prevent continuous corruption;

4. Review : Regularly review the system in a timely manner, encourage good evolution, guide deficiencies, and develop a good technical atmosphere;

4.2 Exception Management

4.2.1 Catching exceptions

Exception capture is also easy to go to two extremes, one is try-catch for each method, and there are multiple groups in one method. The other is that the entire link does not have a try-catch and is in a streaking state. So how to catch exceptions? First look at the purpose of catching exceptions:

1. Pre-judgment and processing of exceptions to allow the process to continue;

2. Quickly find and locate problems to ensure the stability of the system;

Based on the purpose of exception handling, the corresponding processing strategy is also clear:

1. If it is for the continuation of the process, the exception must be caught and processed at the corresponding node;

2. If it is to quickly find and locate the problem, then you can perform unified capture processing at the call entry, and there will be detailed reasons for the exception in the exception stack;

In short, exceptions need to be caught, but where and how to catch them, we can handle them flexibly according to the purpose.

4.2.2 Handling exceptions

1. Business and system exceptions should leave traces to facilitate future problem location and statistical analysis, such as logs, messages, etc.;

2. Regular encoding of various abnormalities can quickly locate problems and facilitate the setting of emergency plans. The rules can refer to HTTP request response encoding;

3. Print the exception stack information, which is an important means to quickly locate the cause of the problem;

4. Longitudinal statistics and comparison of abnormal data to facilitate identification of system health status;

4.3 Log Management

1. Unify the log framework, it is recommended to use the SLF4J log facade framework, and choose Log4j2, Logback, etc. for specific implementation;

2. Configure the log framework, including log output format, output location, output level, output method (asynchronous printing), etc.;

3. Use different levels to record different types of information and print them into different files;

4. Regularly check and clean up log files to avoid taking up too much disk space;

5. According to the needs, the log information can be sent to other systems or analyzed and processed, so as to better monitor and manage the system;

6. If necessary, build the ability to dynamically adjust the log level;

4.4 Monitoring and management

1. System performance monitoring: monitor the usage of CPU, memory, disk, network and other resources of the system, as well as the running status of applications. Such as Nagios, Zabbix;

2. Log monitoring: monitor system and application log information, introduce traceId and business identity Id, and find abnormal situations in time. Such as ELK (Elasticsearch, Logstash, Kibana);

3. Security monitoring: monitor the security status of the system and application programs, and discover potential security threats in time. Such as Snort, Suricata;

4. Business monitoring: monitor various indicators of the business system, visit volume, response time, error rate, etc., and discover business abnormalities in a timely manner. Such as Grafana, Prometheus;

5. Call link tracking: It can track the call link of a request in the entire distributed system, record the processing time and status of each service node, and aggregate this information to form a complete call link graph, so that for analyzing and troubleshooting problems. Such as: Zipkin, SkyWalking;

6. Monitoring and early warning: Various monitoring tools are an effective way to assist in quickly locating problems. If you want to find problems in the first place, it is essential to improve and effective early warning and contact mechanism. Such as email, corporate WeChat, SMS, phone calls, etc.;

4.5 Collaborative Consensus

4.5.1 Do all HTTP service requests use POST?

Recently, our APP encountered a problem. In some cases, service calls returned an "HTTP 414 URI Too Long" response error. The root cause of this problem is that Tomcat's default get request length limit (including request line and request header) exceeds 8192 characters. To solve this problem, there are several options:

1. Relax the restriction by modifying the maxHttpHeaderSize attribute value in the Connector element in the server.xml file (for example: to 16384);

2. Adjust the request protocol of the service from only supporting the GET method to supporting the POST request method at the same time, because the POST request method does not have this size limit;

3. Streamline Header request parameters, standardize and limit the writing of cookies and business parameters;

Solution 1, expanding the container limit of Tomcat, seems to be possible in the short term, but this is a public problem. Thousands of application containers may be needed to be adjusted, and it is a temporary solution rather than a permanent cure.

The second option is to adjust all the GET request methods to support the POST request method at the same time. There are hundreds of applications involved, and the workload is quite a lot.

Solution 3, streamlining the header request parameters is the most reasonable and safe, and it is also the essential cause of the problem. However, it is also very difficult when it involves the interaction between two APPs and the collaborative sorting and transformation of dozens or hundreds of departments.

If it were you, how would you choose a solution?

4.5.2 The front end does not do logic processing, but only data rendering?

Front-end perspective : Since the APP version release involves version review, user download and update and other processes, on the one hand, the cycle is long, and on the other hand, users can refuse to upgrade. This led to the front-end research and development put forward the slogan "the front-end does not do business logic processing, but only data rendering". If the front-end undertakes business logic processing, on the one hand, if a bug occurs, it will be very expensive to fix it, and it cannot even be fixed if the user does not upgrade the version. On the other hand, if the front-end undertakes part of the business logic, it will be difficult to clearly distinguish the boundaries of responsibilities with the back-end, which will bury hidden dangers for collaboration.

Back-end perspective : a default background image, a prompt copy, a font color... Do we need to send all these predictable data that will not be adjusted? Increased data complexity and increased network bandwidth. Moreover, the front end also has hot update technology, and complex pages that are easy to change can also be realized through H5, so why can't we do some simple business logic!

How should the program be selected?

4.5.3 Summary

The solutions to many technical problems have no obvious bias, depending on the environment and position at the time. For example, the most reasonable solution to the problem of excessively long HTTP GET request parameters is to simplify the Header parameters, but this requires long-term efforts and is difficult to achieve in the short term. Therefore, when solving the current problem, we can consider other two options. Similarly, for the question of whether the front-end should handle business logic, we need to consider our positioning of the APP and the construction of the basic capabilities of the front-end and back-end. The criteria for judging a good solution should be : it can solve the current problem at low cost, and does not introduce new problems.

Five Summary

This article details several important aspects that need to be paid attention to when building a system engineering architecture. Make decisions based on the value of the product. And starting from the evolution of system engineering architecture, the selection of technical solutions, and the reaching of consensus on system specifications, it gives solutions to common problems in the implementation process. Finally, I use the "marking the moon finger" in the "Langa Sutra" as the concluding remark to share with the readers: "It is like pointing at the moon with a humble opinion, but you can't see the moon by looking at the finger. Those who memorize the name will not see my truth."