À l'exception des très petits projets de niveau micro-démo, il est recommandé d'utiliser pri pour stocker les fichiers de code dans différents dossiers pour d'autres projets, ce qui est pratique pour une gestion et une recherche unifiées. Il est recommandé de regrouper des classes avec le même type de fonction. S'il y a trop de fichiers de code dans ce répertoire, il est également recommandé de diviser plusieurs répertoires pour le stockage. Par exemple, le formulaire de configuration du système est placé dans un répertoire, et le formulaire de gestion du journal est placé dans un sous contenu.

De nombreuses fonctions communes seront utilisées par plusieurs projets. Vous pouvez envisager de les encapsuler dans des modules de style pri, communément appelés roues, et améliorer constamment ces roues. Plusieurs projets partagent ce module. Une fois que vous rencontrez un correctif de bogue, il vous suffit de modifier une place.

Si le projet est encore plus important ou si l'équipe du projet attribue des fonctions différentes, vous pouvez envisager la forme de plug-in. Généralement, il existe deux types de plug-ins, l'un est le plug-in sous la forme d'une bibliothèque dynamique commune, qui doit être mis en place avec le programme principal, l'autre est le mécanisme Qt. Plugins, placés dans le répertoire spécifié. S'il n'y a que 3 à 5 projets d'interface, créez un form.pri pour stocker ces interfaces.

L'architecture peut être divisée en architecture métier, architecture d'application, architecture de données et architecture technique en fonction des différents besoins, des exigences métier à la mise en œuvre du système.

1. Structure de l'entreprise

Principes de conception de l'architecture d'entreprise :

Plateformez votre entreprise. Les plateformes commerciales sont indépendantes les unes des autres, telles que les plateformes de trading, les plateformes logistiques, les plateformes de paiement, les plateformes publicitaires, etc. L'activité de base est en train de couler et peut être réutilisée, comme les utilisateurs, les produits, les catégories, les promotions, l'actualité, etc.
Séparation du cœur de métier et du non cœur de métier. Séparez les activités principales et non essentielles du système de commerce électronique, telles que le service de transaction principal et le service de transaction général, rationalisez l'activité principale (bon pour la stabilité) et diversifiez les activités non essentielles.
Séparez les différents types d'entreprises. Le rôle de la plateforme de trading est de permettre aux acheteurs et aux vendeurs de signer des contrats de transaction, il faut donc privilégier la haute disponibilité pour que les utilisateurs puissent passer des commandes rapidement. L'activité d'exécution n'a pas d'exigences élevées en matière de disponibilité, mais la priorité doit être donnée à la cohérence. L'activité de seckill a des exigences élevées en matière de simultanéité élevée et doit être séparée des activités régulières.
Distinguer les processus principaux et auxiliaires.

2. Architecture des applications

Principes de conception de l'architecture d'application :

Stabiliser. Tout tourne autour de la stabilité. La structure doit être aussi simple et claire que possible, et la poursuite de petits et beaux, pas grands et complets. Ne surdimensionnez pas.
Découplage. Séparez la partie stable de la partie volatile. Séparation du cœur de métier du non cœur de métier. Séparez les applications des données. Séparation des services et détails de mise en œuvre.
abstrait. Abstraction d'application : l'application dépend uniquement de l'abstraction du service, et non des détails et de l'emplacement de l'implémentation du service. Abstraction de la base de données : l'application ne dépend que de la base de données logique et n'a pas besoin de se soucier de l'emplacement et de la fragmentation de la base de données physique. Abstraction de service : le déploiement de la virtualisation d'applications n'a pas besoin de se soucier de la configuration de la machine physique et alloue dynamiquement les ressources.
couplage lâche. Appels interdomaines asynchrones : essayez de découpler de manière asynchrone entre différents domaines d'activité. Rendez les activités non essentielles aussi asynchrones que possible : essayez de les rendre aussi asynchrones que possible entre les activités principales et les activités non essentielles. Lorsqu'il est nécessaire d'appeler de manière synchrone, vous devez définir le délai d'expiration et la longueur de la file d'attente des tâches.
conception tolérante aux pannes. Autonomie des services : les services peuvent être modifiés, déployés, publiés et gérés indépendamment les uns des autres pour éviter les réactions en chaîne. Tolérance aux pannes du cluster : déploiement du cluster du système d'application, évitant les services à point unique. Reprise après sinistre multi-salles informatiques : déploiement multi-salles informatiques, multi-actif.

Il existe plusieurs types principaux d'architectures d'applications : les architectures monolithiques, distribuées et SOA.

2.1 Application monolithique

Le système n'a qu'une seule application, qui est regroupée dans une seule application, déployée sur une machine et stocke les données dans une base de données. L'application monolithique adopte une architecture en couches, comprenant généralement la couche de présentation, la couche métier, la couche d'accès aux données et la couche de base de données. La couche de présentation est responsable de l'expérience utilisateur, la couche métier est responsable de la logique métier et la couche d'accès aux données est responsable pour l'accès aux données dans la couche DB.

Avantages : Développement, compilation et débogage à guichet unique, une application contient toutes les fonctions, facile à tester et à déployer.
Inconvénients : Lorsque le système s'agrandit, la complexité du code est élevée, il est difficile à maintenir, le niveau d'expansion des applications est faible et la division des responsabilités de l'entreprise et des modules n'est pas claire.

2.2 Architecture distribuée

Dans l'architecture d'application distribuée, ils sont indépendants les uns des autres, les codes sont développés indépendamment, déployés indépendamment et communiquent entre eux via des interfaces API. Le protocole de communication utilise généralement HTTP, le format de données est JSON et la méthode d'intégration de l'application est relativement simplifiée.

Avantages : Cohésion élevée au sein de l'application, développement, test et déploiement indépendants, couplage lâche entre les applications, limites commerciales claires, dépendances commerciales claires et prise en charge du développement parallèle de grands projets.
Inconvénients : lorsque les exigences de l'interface API changent, l'application doit être redéployée, et la fiabilité de la communication et l'encapsulation des données sont relativement médiocres par rapport aux appels en cours.

2.3 Architecture SOA

La SOA est également une sorte d'architecture d'application distribuée. L'architecture SOA fournit une gouvernance des services de support, y compris l'enregistrement des services, le routage des services, l'autorisation des services, la dégradation des services, la surveillance des services, etc.

Avantages : se concentrer sur la couche de service, se concentrer sur le cœur de métier et fournir le partage de l'ensemble du système. Le service est une application indépendante, déployée indépendamment, avec une interface claire, et il est facile d'effectuer des tests et un déploiement automatisés. Le le service est sans état et facile à mettre à l'échelle horizontalement ; grâce à la technologie de virtualisation des conteneurs, l'isolation des pannes et l'utilisation efficace des ressources sont réalisées.
Inconvénients : dépendances système complexes, inconvénients pour le développement/test/déploiement, difficultés de cohérence des données distribuées et de prise en charge des transactions distribuées, généralement résolus en simplifiant la cohérence finale

3. Architecture technique

L'architecture technique est la mise en œuvre de solutions techniques pour les fonctions (ou services) proposées dans l'architecture métier, y compris la mise en œuvre du système logiciel, la sélection du système d'exploitation et la conception de l'environnement d'exécution. Principes de conception:

pas de statut. Autrement dit, essayez de ne pas enregistrer les données d'état sur la machine.
Réutilisable. La granularité de réutilisation est un service abstrait avec une logique métier, et non les détails d'implémentation du service. Les références de service dépendent uniquement de l'abstraction de service.
couplage lâche. Appelez à travers les domaines d'activité, découplant autant que possible de manière asynchrone. Définissez le délai d'expiration et la taille de la file d'attente lors d'un appel synchrone. Séparez les services de base relativement stables des services de processus volatils.
maniable. Les services peuvent être rétrogradés, le trafic limité, activé et désactivé, surveillé, un mécanisme de liste blanche et des contrats de service peuvent être formulés.
Prestations de base. Les services de base sont coulants et réutilisables, tels que la ponctualité, l'inventaire et le calcul des prix. Les services de base sont autonomes et relativement indépendants. La mise en œuvre des services de base devrait être rationalisée et évolutive horizontalement. La mise en œuvre des services de base doit être physiquement isolée, y compris les données relatives aux services de base.

4. Résumé de l'architecture du programme

Architecture du programme :
(1) module d'interface utilisateur : responsable du traitement de l'affichage des données à partir de la couche de logique métier ou d'autres modules, et de l'envoi des opérations de l'utilisateur au module de logique métier.
(2) Module de communication : TCP, UDP, mqtt, port série, etc., adoptant le mode singleton pour être responsable de la communication externe.
(3) Module de base de données : lire et enregistrer des données.
(4) Module de logique métier : traitez les données renvoyées par le module de communication et informez le module d'interface utilisateur du résultat.
(5) Couche intermédiaire : module de communication associé et module de logique métier.
(6) Modules indépendants (module de configuration initiale, processus démon, module de mise à jour, module de collecte de logs...).

Les avantages de cet article, gratuit pour recevoir le package de matériel d'apprentissage du développement Qt, vidéo technique, y compris (base du langage C++, introduction à la programmation Qt, signal QT et mécanisme de slot, dessin d'image de développement d'interface QT, réseau QT, programmation de base de données QT, QT project combat, QSS, OpenCV, Quick module, interview questions, etc.)

Architecture du projet Qt : conception de l'architecture