Ajouter des modules à un service réseau modulaire sans briser ses frontières

## Relier les modules par des interfaces partagées, pas par leurs détails internes - Considérez le système de modules comme la frontière centrale d'extension. L'authentification, le stockage, la validation, la transformation, le routage et les points de terminaison de protocole doivent implémenter les interfaces partagées du framework plutôt que s'appeler directement par leurs détails internes. - Conservez les interfaces stables, les primitives de configuration, la gestion des adresses, les types d'erreur et les contrats de journalisation dans une couche de framework réutilisable. Placez les implémentations concrètes dans des paquets internes organisés par rôle. - Gardez le point d'entrée de l'exécutable minimal. Il doit charger le paquet du service, vérifier que les modules intégrés sont enregistrés et lancer la séquence de démarrage. - Reliez les modules de premier niveau par la configuration et un registre à initialisation différée. Faites passer chaque requête ou message dans une chaîne de traitement explicite composée de validateurs, de modificateurs et de cibles choisies selon des règles de correspondance. - Évitez les dépendances circulaires en faisant dépendre les implémentations d'interfaces stables plutôt que d'implémentations de même niveau. ## Compiler avec l'outil de compilation du dépôt et lancer les tests concernés - Utilisez l'outil d'encapsulation de compilation du dépôt comme chemin de compilation canonique, avec les étiquettes de compilation ou les options fonctionnelles qu'il prend en charge. Ne le remplacez pas par une commande de compilation improvisée qui omet les métadonnées de version ou des indicateurs obligatoires. - Exécutez la suite complète de tests unitaires pour les modifications transversales. Lorsque le comportement franchit des frontières de protocole, de stockage ou de livraison, exécutez le banc d'essai d'intégration depuis son répertoire de travail documenté. - Préservez l'injection de version réalisée par le système de compilation. Si l'environnement d'exécution utilise une dépendance adossée à du code natif, vérifiez que le compilateur et les bibliothèques natives nécessaires sont disponibles avant de diagnostiquer le code source. - Pendant les itérations, privilégiez un test ciblé sur le paquet, puis exécutez le parcours d'intégration directement affecté avant de terminer. Signalez tout test omis et la raison environnementale concrète. ## Ajouter un nouveau module dans le dossier de son rôle et l'enregistrer 1. Placez l'implémentation dans le répertoire interne correspondant à son rôle, par exemple validation, destination, authentification, stockage, recherche, transformation ou gestion des points de terminaison. 2. Implémentez à la fois l'interface commune du cycle de vie des modules et l'interface propre au rôle. Conservez les contrats de rôle dans la couche stable du framework. 3. Enregistrez la fabrique pendant l'initialisation du paquet en suivant la convention établie de nommage avec préfixe de rôle. 4. Ajoutez l'implémentation à l'assemblage des modules intégrés du service au moyen de l'importation d'enregistrement ou du manifeste désigné par le dépôt. Lorsque tel est le modèle établi, le code d'enregistrement doit rester limité à cet effet de bord. 5. Partez d'un squelette ou d'un utilitaire existant pour ce rôle, s'il en existe un. N'utilisez l'utilitaire sans état que si le module ne conserve réellement aucun état mutable entre les requêtes. 6. Ajoutez des tests ciblés sur la configuration, l'enregistrement, le fonctionnement nominal, les défaillances temporaires et la correspondance des erreurs aux frontières. ## Renvoyer des erreurs qui indiquent si l'on peut réessayer et masquent les détails internes - Utilisez le paquet d'erreurs structurées du framework pour les erreurs qui franchissent les frontières entre modules. Ne renvoyez pas une erreur mise en forme mais non classée lorsque l'appelant a besoin de l'état du protocole, du comportement de nouvelle tentative ou de l'attribution au module. - Indiquez le code d'état externe, l'état étendu ou le sous-type lorsqu'il est pris en charge, un message générique sûr pour le client et le nom de la vérification ou de la destination responsable. - Marquez explicitement les défaillances transitoires afin que les répartiteurs puissent distinguer les situations permettant une nouvelle tentative des rejets permanents. - Ne laissez pas la configuration du serveur, les chemins internes, les identifiants d'accès ou les détails d'implémentation apparaître dans les messages visibles par le client. - Ajoutez des champs de diagnostic structurés aux défaillances internes inattendues et consignez-les au moyen du journaliseur du framework. Conservez la cause d'origine sans l'exposer aux clients distants. ## Ne partager aucun état entre requêtes et intercepter les panics des tâches en arrière-plan - Ne partagez jamais entre des requêtes ou des messages un état mutable propre à une requête. Supposez que les vérifications et les transformations s'exécutent de façon concurrente, sauf si le contrat du framework les sérialise explicitement. - Toute goroutine ou tâche d'arrière-plan lancée doit intercepter les panics à sa frontière, consigner la défaillance et empêcher qu'une tâche fasse tomber l'ensemble du service. - Normalisez les identifiants externes avant de les comparer ou de les stocker. Pour les identifiants semblables à des domaines, appliquez la représentation Unicode, la forme de normalisation et le repliement de casse Unicode exigés par le framework, au lieu d'inventer un nettoyage local. - Analysez la configuration des modules au moyen de la table de configuration partagée et de la méthode de cycle de vie. Rejetez les réglages inconnus ou non valides de manière cohérente avec les modules existants. - Utilisez le journaliseur du framework plutôt que celui qui est global au langage. Lorsque le framework le permet, créez des journaliseurs à portée d'opération ou de livraison afin que les événements associés conservent leur contexte. - Avant la fusion, vérifiez par des tests l'enregistrement, l'analyse de la configuration, l'exécution concurrente, la normalisation, les défaillances structurées et les journaux à la frontière la plus étroite qui démontre chaque comportement.