Except for very small micro-demo-level projects, it is recommended to use pri to store code files in different folders for other projects, which is convenient for unified management and search. Classes with the same type of function are recommended to be put together. If there are too many code files in this directory, it is also recommended to split multiple directories for storage. For example, the system configuration form is placed in one directory, and the log management form is placed in one Under contents.

Many common functions will be used by multiple projects. You can consider encapsulating them into pri-style modules, commonly known as wheels, and constantly improve these wheels. Multiple projects share this module. Once you encounter a bug fix, you only need to change one place.

If the project is still larger or the project team assigns different functions, you can consider the plug-in form. Generally, there are two types of plug-ins, one is the plug-in in the form of a common dynamic library, which must be put together with the main program; the other is the Qt mechanism. Plugins, placed in the specified directory. If there are only 3-5 interface projects, create a form.pri to store these interfaces.

Architecture can be divided into business architecture, application architecture, data architecture, and technical architecture according to different needs from business requirements to system implementation.

1. Business structure

Design principles of business architecture:

Platformize your business. Business platforms are independent of each other, such as trading platforms, logistics platforms, payment platforms, advertising platforms, etc. The basic business is sinking and can be reused, such as users, products, categories, promotions, timeliness, etc.
Separation of core business and non-core business. Separate the core business and non-core business of the e-commerce system, such as the main transaction service and the general transaction service, streamline the core business (good for stability), and diversify the non-core business.
Segregate different types of business. The role of the trading platform is to allow buyers and sellers to sign transaction contracts, so it is necessary to prioritize high availability so that users can place orders quickly. The fulfillment business does not have high requirements on availability, but priority must be given to ensuring consistency. The seckill business has high requirements for high concurrency and should be separated from regular business.
Distinguish between main and auxiliary processes.

2. Application Architecture

Design principles of application architecture:

Stablize. Everything revolves around stability. The structure should be as simple and clear as possible, and the pursuit of small and beautiful, not big and comprehensive. Don't overdesign.
Decoupling. Separate the stable part from the volatile part. Separation of core business from non-core business. Separate applications from data. Separation of services and implementation details.
abstract. Application abstraction: The application only depends on the service abstraction, not on the details and location of the service implementation. Database abstraction: The application only depends on the logical database, and does not need to care about the location and fragmentation of the physical database. Service abstraction: Application virtualization deployment does not need to care about the configuration of the physical machine, and dynamically allocates resources.
loosely coupled. Asynchronous cross-domain calls: try to decouple asynchronously between different business domains. Make non-core business as asynchronous as possible: try to make it as asynchronous as possible between core business and non-core business. When it is necessary to call synchronously, you need to set the timeout period and the length of the task queue.
fault-tolerant design. Service autonomy: Services can be modified, deployed, released, and managed independently of each other to avoid chain reactions. Cluster fault tolerance: application system cluster deployment, avoiding single-point services. Multi-computer room disaster recovery: multi-computer room deployment, multi-active.

There are several main types of application architectures: monolithic, distributed, and SOA architectures.

2.1 Monolithic application

The system has only one application, which is packaged into one application; deployed on one machine; and stores data in one DB. The monolithic application adopts a layered architecture, generally including the presentation layer, business layer, data access layer, and DB layer. The presentation layer is responsible for user experience, the business layer is responsible for business logic, and the data access layer is responsible for data access in the DB layer.

Advantages: One-stop development, compilation and debugging, one application contains all functions, easy to test and deploy.
Disadvantages: When the system grows larger, the code complexity is high, it is difficult to maintain, the level of application expansion is low, and the division of business and module responsibilities is not clear.

2.2 Distributed Architecture

In the distributed application architecture, they are independent of each other, codes are developed independently, deployed independently, and communicate with each other through API interfaces. The communication protocol generally uses HTTP, the data format is JSON, and the application integration method is relatively simplified.

Advantages: High cohesion within the application, independent development, testing and deployment, loose coupling between applications, clear business boundaries, clear business dependencies, and support for parallel development of large projects.
Disadvantages: When the API interface requirements change, the application needs to be redeployed, and the communication reliability and data encapsulation are relatively poor compared to in-process calls.

2.3 SOA Architecture

SOA is also a kind of distributed application architecture. SOA architecture provides supporting service governance, including service registration, service routing, service authorization, service degradation, service monitoring, etc. Consider the system split more from the business as a whole.

Advantages: focus on the service layer, focus on the core business, and provide the sharing of the entire system. The service is an independent application, independently deployed, with a clear interface, and it is easy to do automated testing and deployment. The service is stateless and easy to scale horizontally ; Through container virtualization technology, fault isolation and resource efficient utilization are realized.
Disadvantages: complex system dependencies, inconvenience to development/testing/deployment, difficulties in distributed data consistency and distributed transaction support, generally solved by simplifying final consistency

3. Technical Architecture

Technical architecture is the implementation of technical solutions for the functions (or services) proposed in the business architecture, including software system implementation, operating system selection, and runtime design. Design Principles:

no status. That is, try not to save the state data on the machine.
Reusable. Reuse granularity is an abstract service with business logic, not the implementation details of the service. Service references only depend on the service abstraction.
loosely coupled. Call across business domains, decoupling as much as possible asynchronously. Set the timeout and queue size when calling synchronously. Separate relatively stable basic services from volatile process services.
manageable. Services can be downgraded, traffic limited, switched on and off, monitored, whitelist mechanism, and service contracts can be formulated.
Basic services. Basic services are sinking and reusable, such as timeliness, inventory and price calculation. Basic services are autonomous and relatively independent. The implementation of basic services should be streamlined and scalable horizontally. The implementation of basic services should be physically isolated, including data related to basic services.

4. Summary of Program Architecture

Program architecture:
(1) UI module: responsible for processing data display from the business logic layer or other modules, and sending user operations to the business logic module.
(2) Communication module: TCP, UDP, mqtt, serial port, etc., adopting singleton mode to be responsible for external communication.
(3) Database module: read and save data.
(4) Business logic module: process the returned data from the communication module, and notify the UI module of the result.
(5) Middle layer: associated communication module and business logic module.
(6) Independent modules (initialization configuration module, daemon process, update module, log collection module...).

The benefits of this article, free to receive Qt development learning materials package, technical video, including (C++ language foundation, introduction to Qt programming, QT signal and slot mechanism, QT interface development-image drawing, QT network, QT database programming, QT project combat, QSS, OpenCV, Quick module, interview questions, etc.) ↓↓↓↓↓↓See below↓↓Click on the bottom of the article to receive the fee↓↓

Qt Project Architecture: Architecture Design