Standards de Génie Logiciel et de Conception de Systèmes
Un guide opérationnel rigoureux et éprouvé pour l'excellence en génie logiciel, l'architecture système, la conception bas niveau et les systèmes distribués.
1. Principes Opérationnels Fondamentaux
- Compromis plutôt que Dogme : Il n'existe pas de « meilleures pratiques » universelles, seulement des compromis. Chaque choix architectural achète un ensemble d'avantages en payant un coût spécifique (latence, cohérence, complexité opérationnelle ou charge cognitive). Indiquez toujours ce qui est sacrifié.
- Réversibilité d'abord : Privilégiez les décisions à double sens (réversibles) plutôt que les décisions à sens unique (irréversibles). Évitez le couplage prématuré à des fournisseurs, frameworks ou topologies distribuées spécifiques.
- Pas d'Architecture Astronautique : Chaque abstraction, interface et couche doit justifier son poids par rapport à des exigences concrètes existantes, et non à des besoins futurs spéculatifs (YAGNI).
- Conception Basée sur des Preuves : Fondez les décisions sur des profils concrets, des mesures, des plans d'exécution de requêtes (
EXPLAIN ANALYZE) et des limites de capacité, plutôt que sur des hypothèses. - Échec Rapide et Limites Explicites : Les limites entre sous-systèmes, domaines ou sauts réseau doivent avoir des contrats explicites et fortement typés, une validation, des timeouts, des circuit breakers et des garanties d'idempotence.
2. Conception Haut Niveau (HLD) et Workflow d'Architecture
Lorsqu'on vous demande de concevoir un système, d'évaluer une architecture ou de refactoriser un sous-système majeur, exécutez ce cadre en 6 étapes :
flowchart TD
Step1["1. Clarifier les Exigences et le Périmètre<br>(Fonctionnel, Non Fonctionnel, Latence, Disponibilité, Cohérence)"]
Step2["2. Estimation de Capacité et d'Échelle<br>(DAU, QPS, Débit, Bande Passante Réseau, Stockage, RAM Cache)"]
Step3["3. Architecture Haut Niveau (C4 L1/L2)<br>(Limites des Services, Sélection du Stockage, Entrée, Mise en Cache)"]
Step4["4. Modèle de Données et Contrats d'Interface<br>(Entités, Schémas, Clés Primaires, Index, API REST/gRPC)"]
Step5["5. Analyses Approfondies et Isolement des Goulots d'Étranglement<br>(Réplication, Partitionnement, Concurrence, Pathologies du Cache, Points Chauds)"]
Step6["6. Stratégie de Résilience et SRE<br>(SLOs, Circuit Breakers, Nouvelles Tentatives avec Jitter, Idempotence, DLQs)"]
Step1 --> Step2 --> Step3 --> Step4 --> Step5 --> Step6
Référence HLD Détaillée
Pour les théorèmes des systèmes distribués (CAP, PACELC), les hiérarchies de cohérence, le consensus (Raft/Paxos), le partitionnement (sharding), la réplication, le motif Saga et le motif Transactional Outbox, consultez : 👉 Référence Conception Haut Niveau et Systèmes Distribués
3. Conception Bas Niveau (LLD) et Standards de Code Propre
Lors de l'écriture, de la révision ou du refactoring de code, respectez ces standards :
3.1 Les Règles SOLID
- SRP (Responsabilité Unique) : Un module répond à un seul acteur/partie prenante. Extrayez la persistance, la sérialisation HTTP et la logique métier dans des préoccupations séparées.
- OCP (Ouvert/Fermé) : Préférez les motifs Polymorphisme, Stratégie ou Visiteur plutôt que des instructions
switch/if-elsetentaculaires pour le dispatch de type. - LSP (Substitution de Liskov) : Les sous-types doivent satisfaire tous les invariants comportementaux du parent. Remplacer des méthodes pour lancer
NotImplementedExceptionviole LSP. - ISP (Ségrégation des Interfaces) : Favorisez des interfaces de rôle petites et spécifiques au client plutôt que des « interfaces Dieu » larges.
- DIP (Inversion des Dépendances) : Les règles métier centrales dépendent uniquement d'abstractions (Ports), jamais directement de bibliothèques de base de données externes, de frameworks UI ou de pilotes réseau.
3.2 Encapsulation Modulaire (Parnas et Connascence)
- Secrets du Module : Un module doit complètement cacher son secret principal (algorithmes/structures de données internes) et son secret secondaire (environnements externes/formats de fichiers).
- Connascence : Minimisez la connascence dynamique (ordre d'exécution, timing, contraintes de valeur) et réduisez le couplage à des accords statiques de nom/type.
Référence LLD Détaillée
Pour les guides de motifs de conception du Gang of Four (GoF), les blocs de construction tactiques du Domain-Driven Design (DDD) (Entités, Objets Valeur, Agrégats, Événements de Domaine) et les techniques de refactoring, consultez : 👉 Référence Conception Bas Niveau et Code Propre
4. API et Standards de Persistance des Données
- API RESTful :
- Respectez strictement la sémantique des méthodes HTTP (
GETest sûr et idempotent ;PUT/DELETEsont idempotents ;POSTcrée). - Utilisez la RFC 7807 (Problem Details) pour les réponses d'erreur structurées.
- Pour les collections à volume élevé, utilisez la pagination par Keyset/Curseur plutôt que la pagination par Offset/Limit.
- Respectez strictement la sémantique des méthodes HTTP (
- Indexation de Base de Données (Règle E-R-S) :
- Ordre des colonnes d'un index composite : [Colonnes d'Égalité] $ o$ [Colonnes de Plage] $ o$ [Colonnes de Tri].
- Utilisez les Index Couvrants (Index-Only Scans) et les Index Partiels pour éliminer les recherches de pages disque pour les requêtes à chaud.
- Vérifiez toujours les requêtes avec
EXPLAIN QUERY PLANouEXPLAIN ANALYZE.
- Messagerie et Événements Asynchrones :
- Garantissez un traitement effectif unique en combinant une livraison au moins une fois du courtier avec l'idempotence du consommateur (IDs de message uniques dédupliqués dans le stockage).
- Acheminez les messages empoisonnés non traitables (poison pills) vers des Files d'Attente de Lettres Mortes (DLQs) pour éviter le blocage de la partition.
Référence API et Données Détaillée
👉 Conception d'API et Standards de Persistance des Données
5. Ingénierie de Performance, de Capacité et de Fiabilité
- Estimation Rapide (Back-of-the-Envelope) :
- $1 ext{ jour} e approximativement 10^5 ext{ secondes}$ ($86 400 ext{ s}$). $1 ext{M requêtes/jour} e approx. 12 ext{ RPS}$.
- QPS de pointe = QPS moyen $ imes$ $3$.
- RAM Cache = $20% imes ( ext{Volume de Lecture Quotidien} imes ext{Taille de l'Élément})$ (règle de Pareto 80/20).
- Loi de Little : $L = \lambda W$ (Concurrence en vol = Taux d'arrivée $ imes$ Latence).
- Discipline de Mise en Cache :
- Ne définissez jamais de TTL en mémoire arbitraires et non mesurés qui expirent pendant les fenêtres de fonctionnement normales.
- Invalidez en fonction de versions/empreintes de données ou horodatages de session.
- Défendez-vous contre l'Embardée de Cache (utilisez des mutex/verrous distribués), la Pénétration de Cache (filtres de Bloom) et l'Avalanche de Cache (jitter TTL).
- Ingénierie de Fiabilité des Sites (SRE) :
- Imposez des SLO explicites et des budgets de latence ($p50$, $p95$, $p99$).
- Implémentez des Circuit Breakers, des Cloisons (Bulkheads) et un Backoff Exponentiel avec Jitter Complet.
Référence Fiabilité et Performance Détaillée
👉 Référence Ingénierie de Fiabilité, de Performance et de Capacité
6. Enregistrements de Décisions Architecturales (ADR)
Documentez les choix techniques non triviaux en utilisant le format ADR standard :
- Contexte et Moteurs : Le problème, les contraintes opérationnelles et les objectifs de latence/échelle.
- Options Considérées : Alternatives structurelles et leurs compromis.
- Décision et Résultat : Justification concrète liée aux moteurs de décision.
- Conséquences : Avantages positifs explicites ET coûts négatifs acceptés.
Référence et Modèle ADR Détaillés
👉 Référence Enregistrements de Décisions Architecturales et Modèle C4