Architecture Robuste
Produire la plus petite conception dont les garanties peuvent être expliquées et contestées. Les règles guident les décisions ; elles ne certifient pas l'exactitude. Une architecture utile rend explicites les faits importants, donne aux règles un foyer faisant autorité, et reste compréhensible en cas d'échec ou de changement.
Partir d'une conséquence
Pour un système existant, inspectez les points d'entrée réels, les appelants, les magasins d'état et les vérifications avant de faire confiance à des diagrammes ou à des propositions antérieures. Pour un nouveau système, distinguez les exigences des hypothèses ; décrivez le premier flux réel avant de choisir des composants.
N'enregistrez que les contraintes qui modifient une décision : utilisateurs et autorité, volume opérationnel, latence ou budgets de ressources, disponibilité, conditions de défaillance, besoins de récupération et de durabilité, contraintes de déploiement et ce que l'équipe peut exploiter. Demandez le choix produit manquant lorsqu'il modifie l'exactitude. Continuez le travail indépendant et réversible pendant que ce choix est en suspens.
Calibrez l'intervention :
- Écart de modèle / responsabilité : le fait nécessaire, l'opération complète ou l'autorité cohérente est absente ou divisée. Résolvez ce contrat avant de corriger ses lecteurs.
- Défaut de limite : un propriétaire adéquat existe mais un appelant le contourne ou son application est incomplète. Approfondissez ou utilisez ce propriétaire ; un défaut à travers les couches ne nécessite pas en soi une nouvelle architecture.
- Écart produit : le comportement requis n'est pas décidé. Présentez la conséquence concrète et les choix les plus petits, plutôt que de choisir en silence.
- Défaut de présentation / local : les faits sous-jacents corrects nécessitent un rendu, une analyse ou une correction de copie locale. Appliquez la correction locale normale ; arrêtez ici le flux de travail d'architecture.
Un fichier volumineux, une syntaxe dupliquée, un nom de modèle manquant ou un package proposé ne prouve pas en soi un écart de modèle.
Pour les conceptions ou les révisions impliquant l'accès à des ressources protégées, appliquez autorisation si elle est installée. Elle possède le parcours de la politique d'accès ; conservez les règles locales de propriété et de confiance ci-dessous lorsque vous utilisez cette compétence seule.
Donner aux faits et aux règles un foyer
Nommez le fait ou l'invariant, son autorité logique et les opérations autorisées à le modifier. L'autorité peut être une fonction locale, un éditeur de fichier, un descripteur de bibliothèque, un processus ou un service ; elle n'a pas besoin d'être un serveur ou un nouveau module.
- Placez la règle au point qui peut l'appliquer pour chaque producteur concerné. Les adaptateurs d'entrée établissent la confiance de l'appelant, analysent les entrées, invoquent ce propriétaire et traduisent le résultat. Les vérifications précoces utiles améliorent le retour d'information ; les vérifications faisant autorité protègent l'effet réel.
- Modélisez explicitement qui possède les données partagées. Une valeur parent ou de portée manquante n'est pas automatiquement une autorité globale. Appliquez la politique réelle de l'acteur aux lectures, à la sérialisation et aux effets, et pas seulement aux contrôles visibles.
- Séparez les relations actuelles, les faits d'occurrence immuables et les projections. Stockez l'historique ou l'instantané dont la fonctionnalité a réellement besoin. Les relations actuelles ne peuvent pas reconstruire les faits passés manquants ; marquez honnêtement l'historique hérité inconnu.
- Donnez à une tentative son identité d'opération. Deux charges utiles identiques peuvent être des intentions distinctes. Définissez la portée de la clé, la réutilisation inappropriée, la rétention et la relecture sous l'autorité actuelle lorsque l'exactitude de la tentative est importante.
- Donnez aux règles dérivées et aux représentations une définition maintenue là où les consommateurs doivent être d'accord. Préservez les différences intentionnelles entre les publics, les cohortes, les unités et les significations temporelles. Conservez la duplication de présentation locale bon marché lorsque le partage créerait une dépendance artificielle.
- Les conceptions multi-écrivains ou hors ligne explicitement spécifiées sont valides. Nommez la sémantique des conflits, la coordination et le comportement de partition au lieu de supposer qu'un seul écrivain physique peut toujours être imposé.
Une limite gagne son existence en cachant une décision et en supprimant la connaissance des appelants. Vérifiez cela directement : après le changement, quel appelant ne connaît plus la règle, la disposition de stockage ou le séquencement ? Un wrapper qui laisse chaque appelant coordonner les mêmes étapes métier n'a pas déplacé la propriété.
Posséder le résultat complet
Tracez une intention à travers ses effets importants. Énoncez ce qui doit tenir ensemble, le point d'achèvement faisant autorité et ce que l'utilisateur reçoit si l'exécution s'arrête avant ou après ce point.
Énumérez chaque publication observable, y compris les caches et les rappels en arrière-plan. Pour le travail asynchrone, identifiez l'opération, l'identité, la version et la durée de vie auxquelles un résultat appartient, et vérifiez l'applicabilité à chaque limite de publication pertinente. Une vérification de vue tardive ne peut pas protéger une écriture antérieure dans le cache ou le stockage. Distinguez l'annulation d'un consommateur de l'annulation d'un effet métier déjà engagé.
Utilisez une primitive atomique réelle pour les invariants qui nécessitent l'indivisibilité au sein d'une seule autorité. Lorsque des écrivains concurrents peuvent invalider une lecture antérieure, appliquez la portée, l'état et la version pertinents dans l'effet ou une sérialisation équivalente. Faites correspondre le mécanisme à un entrelacement atteignable ; une transformation pure monothread n'a pas besoin de mécanismes de concurrence de type base de données.
Aux limites réseau, processus, fichier ou asynchrones, lisez Vérifications aux limites. Sélectionnez la branche pertinente : effets durables, durée de vie des ressources, travail en temps réel ou état/historique. Une transaction locale ne rend pas un effet externe atomique ; un résultat inconnu n'est pas nécessairement un échec. Définissez la récupération et les résultats partiels/en attente véridiques avant d'ajouter des tentatives.
Pour les API réutilisables, rendez explicites les entrées, les sorties, les refus, la propriété et les responsabilités de nettoyage. Préservez les distinctions significatives d'erreur/contrôle de flux. Placez les diagnostics là où un échec peut être expliqué sans exposer les données protégées ; un journal n'est pas un mécanisme de récupération ni une base de données d'autorisation/historique.
Choisir une structure proportionnelle
Privilégiez le module cohérent existant et les mécanismes de plateforme pris en charge. Dans une nouvelle petite application, quelques fonctions ou modules bien délimités peuvent suffire. Séparez le déploiement ou introduisez une infrastructure lorsqu'une exigence concrète nécessite une mise à l'échelle indépendante, un isolement des défaillances, des contraintes d'exécution ou une propriété organisationnelle. Respectez une plateforme explicitement choisie tout en expliquant un compromis conséquent.
Évaluez le plus petit changement à côté d'une alternative plausible. Expliquez la différence importante en termes d'exactitude, de coût opérationnel/ressource et de réversibilité. Gardez chaque décision de conception dans un seul foyer ; extrayez indépendamment uniquement les coutures stables et utiles. Les dossiers, packages et services physiques suivent les limites éprouvées plutôt que d'en fournir la preuve.
Préservez l'invariant complet lors d'un changement d'emplacement. La migration et le déploiement doivent tenir compte des données existantes, des anciens/nouveaux écrivains, des consommateurs publics et de la compatibilité de retour arrière. La suppression d'une colonne, d'une API ou d'une ressource nécessite la preuve que ses obligations et ses consommateurs ont pris fin.
Essayer de le réfuter
Choisissez une fine tranche verticale qui exerce la limite contestée. Utilisez le stockage, le fichier, le protocole ou la couture de ressource réelle pertinente pour l'affirmation ; isolez uniquement les dépendances externes réelles. Pour une conception précoce sans implémentation, spécifiez l'expérience discriminante et laissez son résultat inconnu.
Contestez l'invariant avec les défaillances pertinentes : mauvaise autorité, état obsolète, travail répété ou réorganisé, plantage à la limite d'achèvement, annulation, historique manquant/ambigu, et la limite réelle de charge ou de temporisation. Utilisez des leurres explicites et des entrelacements ou horloges contrôlés lorsqu'ils distinguent la règle. Un test doit échouer lorsque cette règle est supprimée, pas seulement compter les appels simulés ou reconnaître les noms choisis.
Vérifiez la sûreté et le progrès : comment une opération valide se termine finalement ou donne un refus honnête ; comment le travail en attente est récupéré ; comment la mémoire, les files d'attente, les connexions et la latence restent bornées. Sélectionnez ces vérifications à partir de l'enveloppe opérationnelle plutôt que de répéter chaque défaillance théorique.
Observez le flux monté/utilisateur ou de bibliothèque publique lorsque vous prétendez qu'il fonctionne. Les assertions unitaires, les diagrammes, les tentatives vertes, les suppositions de benchmark et les dispositifs synthétiques n'établissent que leur propre limite testée. Séparez les résultats mesurés, les résultats de source, les hypothèses, les décisions manquantes et les preuves non exécutées.
Fournir une décision révisable
Adaptez la sortie à la décision. Pour une conception substantielle, fournissez :
- Le flux concret, les contraintes et les inconnues importantes.
- Les invariants, les autorités nommées et les producteurs/consommateurs concernés.
- Les limites d'état/historique, de confiance, d'achèvement et de défaillance, avec des contrats suffisants pour tracer un succès et un échec.
- La petite structure choisie, une alternative pertinente et pourquoi le compromis est approprié.
- Une première tranche avec des vérifications observables d'acceptation, de récupération et d'évolution/déploiement.
- Ce qui est prêt, ce qui nécessite une décision produit ou une preuve, et ce qui a été réellement vérifié.
Utilisez un petit diagramme uniquement lorsqu'il clarifie une limite. Sautez les sections de modèle vides pour une correction locale. Préservez la portée de l'utilisateur : une demande de conception/révision produit une décision, pas une autorisation d'implémenter, migrer, déployer, publier ou modifier des données en direct.
Lors de l'adoption ou de l'évaluation de cette compétence, consultez Protocole d'évaluation. Le contexte principal est répertorié dans Fondations ; il éclaire le raisonnement sans valider une conception individuelle.