Glossaire

Action de compensation: Une nouvelle action qui annule l’effet d’une précédente : libérer le stock, rembourser la carte. Elle diffère d’un rollback, car d’autres services ont peut-être déjà vu la première étape.; Outbox et sagas : quand un changement touche deux systèmes
Adaptateur: Le code qui implémente un port pour une technologie donnée : disque local, S3, Google Cloud Storage. L’adaptateur dépend du port, et le cœur ne sait pas quels adaptateurs existent.; Ports et adaptateurs : un seul cœur, plusieurs backends
Adapter: Adaptateur : une enveloppe qui fait rentrer un objet dans une interface pour laquelle il n’a pas été écrit. Un decorator garde l’interface et ajoute du comportement ; un adapter change l’interface.; Design patterns : des formes nommées que tu utilises déjà
ADR: Architecture Decision Record (registre de décision d’architecture) : un fichier court avec Titre, Statut, Contexte, Décision et Conséquences (Michael Nygard, 2011).; Les ADR : écrire le pourquoi d’une décision
Aggregate: Agrégat : un groupe d’objets modifiés comme une seule unité, à travers une seule racine. Ses invariants, les règles qui doivent toujours tenir, sont vérifiés à l’intérieur.; Les briques du DDD : à l’intérieur d’un bounded context
Alerte sur symptôme: Réveille un humain quand les utilisateurs souffrent (erreurs, lenteur), pas quand une cause pourrait les faire souffrir plus tard (CPU à 80 %).; Observabilité : logs, métriques, traces
Allowlist: Une règle qui interdit tout sauf ce qu’elle nomme. Les exceptions connues sont listées une par une, donc une nouvelle violation ne peut pas passer inaperçue.; Fitness functions : des décisions qui se vérifient toutes seules
Altitude: La quantité de détail dont un public a besoin pour agir sur une décision.; Une décision, trois publics
Anti-corruption layer: Couche anti-corruption : une couche de traduction dans le contexte en aval, qui réécrit le modèle de l’amont avec ses propres termes. Le reste de son code ne voit jamais les mots étrangers.; Bounded contexts et context maps
Appel synchrone: L’appelant attend la réponse. Il obtient le résultat, ou l’erreur, tout de suite.; Appels synchrones ou jobs asynchrones
Architect Elevator: L’image de Hohpe : l’architecte fait l’ascenseur entre la salle des machines de l’IT et le penthouse de la direction, et garde les deux connectés.; Une décision, trois publics
Architecture: Les décisions difficiles à changer plus tard et qui façonnent tout le reste : comment le système est découpé, où vit l’état, comment les parties se parlent.; L’architecture logicielle : les décisions coûteuses à changer
Architecture transitoire: Du code qui fait tourner l’ancien et le nouveau côte à côte, et que tu prévois de supprimer. Fowler : « du code qui disparaîtra une fois la modernisation terminée ».; Faire évoluer un système en marche sans l’arrêter
At-least-once: Au moins une fois : un message n’est jamais perdu une fois que le broker l’a accepté, mais peut arriver deux fois. Le consommateur ne confirme qu’une fois le travail fait, et dédoublonne.; Messaging : files, garanties de livraison et dead letters
Authentification: Vérifier qui est l’appelant : un mot de passe une fois, puis un token à chaque requête.; Gateways, tokens et SSO
Autorisation: Décider ce que cet appelant peut faire sur ces données. Il faut les règles des données, donc c’est le propriétaire des données qui le fait.; Gateways, tokens et SSO
Backfill: Remplir la nouvelle forme pour les lignes écrites avant qu’elle existe. Dans la migration, en tâche de fond par lots, ou pas du tout si le code lit « vide » sans danger.; Migrations de schéma et de données
Bounded context: Bounded context (contexte délimité) : une frontière à l’intérieur de laquelle chaque terme a exactement un sens. Souvent un service ou une équipe.; Bounded contexts et context maps
Bulkhead (cloison): Des pools, des files ou des limites séparés par type de travail, pour qu’un type puisse saturer sans affamer les autres. Le nom vient des cloisons étanches dans la coque d’un navire.; Résilience : empêcher une panne de se propager
C4: Quatre niveaux de zoom pour les diagrammes : Contexte, Conteneurs, Composants, Code. Tu dessines rarement le quatrième.; Le diagramme de contexte : ton système en une seule boîte
Câblage: L’unique endroit qui choisit un adaptateur et le donne au cœur. Pour changer de backend, tu changes le choix à cet endroit.; Ports et adaptateurs : un seul cœur, plusieurs backends
Caractéristique: Une qualité que le système doit avoir et qui n’est pas une fonctionnalité : latence, débit, disponibilité, sécurité… On parle souvent d’une « -ilité ».; Les caractéristiques d’architecture : choisir les trois principales
Chain of responsibility: Chaîne de responsabilité : une requête traverse une liste de handlers dans l’ordre. Chacun peut la modifier, la passer au suivant, ou l’arrêter.; Design patterns : des formes nommées que tu utilises déjà
Changement rétrocompatible: Les anciens consommateurs continuent de marcher sans rien changer de leur côté : un nouvel endpoint, un nouveau champ optionnel. Supprimer, renommer ou changer le type d’un champ, ou lui donner un nouveau sens, est un changement cassant.; Conception et versionnement d’API
Circuit breaker: Après trop d’échecs, arrête d’appeler une dépendance pendant un moment et échoue tout de suite. Puis laisse passer quelques appels d’essai pour voir si elle s’est rétablie.; Résilience : empêcher une panne de se propager
Clé d’idempotence: Une valeur unique que le client envoie avec une requête, et renvoie à chaque retry de cette requête, pour que le serveur repère la répétition.; L’échec : timeouts, retries, idempotence
Clé de partition: Le champ qui décide dans quelle partition va une ligne. Une requête qui la nomme lit une seule partition. Une requête qui ne la nomme pas doit les interroger toutes.; Faire grandir les données
Cœur (core): Ce qui te distingue de tes concurrents. C’est complexe et ça change souvent, donc tu le construis en interne avec tes meilleurs éléments.; Sous-domaines cœur, support et générique
Cohésion: À quel point les parties d’un module servent le même travail. Cohésion faible : un module qui fait deux choses sans rapport.; Couplage et cohésion dans un service de checkout
Competing consumers: Plusieurs consommateurs lisent la même queue (file), et chaque message ne va qu’à l’un d’eux. Avec plus de consommateurs, tu traites plus de messages par seconde, mais ils peuvent finir dans le désordre.; Messaging : files, garanties de livraison et dead letters
Composition root (racine de composition): Le seul endroit autorisé à connaître à la fois une interface et son implémentation, pour les brancher ensemble. Ici, le DataModule Hilt.; Les couches : les imports ne vont que dans un sens
Compromis (trade-off): Ce que tu abandonnes pour obtenir ce que tu veux. La première loi de l’architecture logicielle dit que chaque décision en a un : « Tout, en architecture logicielle, est un compromis. »; L’architecture logicielle : les décisions coûteuses à changer
Conformist: Conformiste : le contexte en aval (celui qui reçoit) reprend le modèle de l’amont tel quel, parce qu’il n’a pas son mot à dire ou que traduire coûte trop cher.; Bounded contexts et context maps
Conséquences: Tout ce qui découle de la décision, le bon et le mauvais. Si tu n’as listé aucun inconvénient, cherche encore (première loi).; Les ADR : écrire le pourquoi d’une décision
Consumer-driven contract (contrat piloté par le consommateur): Chaque consommateur écrit la partie d’un message ou d’une API qu’il lit vraiment, et le producteur fait tourner ces attentes dans sa propre CI. L’outil Pact met en œuvre ce pattern.; Stratégie de test
Conteneur (C4): Quelque chose qui doit tourner pour que le système marche, sous forme d’un processus ou d’un stockage de données : une appli serveur, une base de données, une appli navigateur, un worker.; Les conteneurs : ce qui tourne vraiment
Contexte du système: Niveau 1. Ton système en une seule boîte, plus les personnes et les systèmes externes autour.; Le diagramme de contexte : ton système en une seule boîte
Copie: Une donnée que tu gardes sans en être propriétaire. Elle peut dater, donc tu dois savoir qui la met à jour, et tu ne la modifies jamais toi-même.; À qui appartiennent les données
Couche: Un ensemble de code avec un seul type de travail : dessiner l’écran, appliquer les règles de l’appli, stocker et récupérer les données.; Les couches : les imports ne vont que dans un sens
Couche ouverte: Une couche que celle du dessus peut sauter, pour appeler directement la couche en dessous. Avec une couche fermée, chaque appel doit passer par elle.; Les couches : les imports ne vont que dans un sens
Couplage: Ce qu’un module doit savoir d’un autre pour fonctionner. Plus de couplage veut dire qu’un changement dans l’un force un changement dans l’autre.; Couplage et cohésion dans un service de checkout
Couplage dynamique: Il se produit à l’exécution : un appel gRPC, un message dans une file. Aucun import ne relie les deux côtés, donc grep ne le voit pas.; Couplage et cohésion dans un service de checkout
Couplage statique: Visible dans le code ou le build : imports, bibliothèques partagées, code généré. Un compilateur ou un grep le trouve.; Couplage et cohésion dans un service de checkout
CQRS: Command Query Responsibility Segregation : un modèle pour modifier les données, un autre pour les lire. Martin Fowler attribue sa description à Greg Young. Il n’exige pas l’event sourcing.; CQRS et event sourcing
Dead set: L’endroit où Sidekiq garde un job après son dernier retry raté, pour qu’une personne puisse l’examiner. Un job peut refuser ce mécanisme et être jeté à la place.; Appels synchrones ou jobs asynchrones
Dead-letter queue (DLQ): La queue où le broker range les messages qui ont échoué trop de fois. Quelqu’un doit recevoir une alerte, lire chaque message et décider quoi en faire.; Messaging : files, garanties de livraison et dead letters
Déclenchée ou continue: Les vérifications déclenchées tournent sur un événement (un commit, une release, un lancement manuel). Les continues tournent en permanence, comme le monitoring de production.; Fitness functions : des décisions qui se vérifient toutes seules
Décorateur: Une classe qui implémente le port et enveloppe d’autres implémentations du même port, pour ajouter un seul comportement, par exemple copier chaque envoi vers un second stockage.; Ports et adaptateurs : un seul cœur, plusieurs backends
Dégradation gracieuse: L’appli continue de servir ce qui marche et laisse de côté ce qui ne marche pas. La page n’affiche pas de recommandations, et le checkout fonctionne toujours.; Résilience : empêcher une panne de se propager
Dépréciation: Annoncer que quelque chose va disparaître pendant que ça marche encore. Ensuite, compter qui l’appelle encore, et le supprimer à une date donnée (le sunset).; Conception et versionnement d’API
Dérive: Le code qui s’éloigne lentement d’une décision, un changement d’apparence raisonnable à la fois.; Fitness functions : des décisions qui se vérifient toutes seules
Déterminante: Se dit des quelques caractéristiques qui façonnent la conception. Garde cette liste aussi courte que possible, trois au plus.; Les caractéristiques d’architecture : choisir les trois principales
Diagramme de conteneurs: Niveau 2 de C4. Les conteneurs dans ton système, la technologie de chacun, et la façon dont ils communiquent.; Les conteneurs : ce qui tourne vraiment
Diagramme de déploiement: Où tournent les instances de conteneurs, sur quelles machines ou quels clusters, pour un environnement donné.; Le déploiement : des boîtes sur des machines
Diagramme de flux de données: Des boîtes pour les processus et les stockages, des flèches pour les données, les parties externes dessinées à part. La carte sur laquelle se fait un threat model.; Modélisation des menaces
Diagramme dynamique: Une vue C4 d’un cas d’usage à l’exécution : les mêmes boîtes que les diagrammes statiques, avec des étapes numérotées.; Suivre une requête de bout en bout
Double écriture (dual write): Ton code écrit dans deux stockages l’un après l’autre, sans rien qui garantisse que les deux réussissent ou que les deux échouent.; La cohérence entre plusieurs stockages
Entity: Entité : un objet qui a une identité, et cette identité dure pendant que ses attributs changent. Leo reste le même animal quand on corrige son nom ou sa date de naissance.; Les briques du DDD : à l’intérieur d’un bounded context
Événement: Un fait qui s’est produit, nommé au passé et jamais modifié : OrderCancelled. Le store garde les événements dans l’ordre et les numérote par stream.; CQRS et event sourcing
Événement publié: Un message que le propriétaire envoie après un changement (« prix modifié »), pour que les autres puissent réagir sans lire sa base.; À qui appartiennent les données
Event store: Un journal d’événements en ajout seul (append-only), un stream par agrégat. Rejouer un stream donne l’état courant de l’agrégat.; CQRS et event sourcing
Event-driven: Pilotée par les événements : les parties réagissent à des événements au lieu de s’appeler directement. Bien pour découpler, plus dur à tracer et à tester.; Les styles d’architecture
Expand / contract: Aussi appelé parallel change. Ajoute la nouvelle forme à côté de l’ancienne, fais basculer les lecteurs et les écrivains, supprime l’ancienne forme en dernier. Les trois étapes sortent souvent dans trois releases.; Migrations de schéma et de données
Fail open, fail closed: Ce que fait un contrôle quand il ne peut pas s’exécuter. Fail open laisse passer la requête. Fail closed la refuse.; Les scénarios de qualité : rendre « sécurisé » testable
Fan-out: Un événement qui déclenche plein de jobs : un post copié dans le fil de chaque abonné, et envoyé au serveur de chaque abonné.; Suivre une requête de bout en bout
Fan-out: Transformer un job en plusieurs : ici, un job de livraison par inbox distante au lieu d’un seul pour tout le post.; Appels synchrones ou jobs asynchrones
Feature flag: Un interrupteur qui active un comportement par déploiement ou par tenant. Il te permet d’annuler un rollout, tant que le désactiver ne laisse pas de nouvelles données derrière.; Les décisions réversibles : portes à sens unique et à double sens
Fitness function: Une vérification objective d’une caractéristique d’architecture. La plupart sont automatisées et font passer ou échouer le build. Le livre admet aussi des vérifications manuelles, qui demandent un humain.; Fitness functions : des décisions qui se vérifient toutes seules
Frontière: La ligne entre ce que ton équipe possède et ce que d’autres possèdent. Tu modifies librement ce qui est dedans. Pour changer ce qui est dehors, tu dois te mettre d’accord avec une autre équipe ou une autre entreprise.; Le diagramme de contexte : ton système en une seule boîte
Frontière de processus: Le code des deux côtés ne peut pas partager de mémoire. Il communique par le réseau, une file ou un fichier, et chaque côté peut planter seul.; Les conteneurs : ce qui tourne vraiment
Générique (generic): Un problème que tout le monde a et que quelqu’un a déjà bien résolu. Tu l’achètes, ou tu adoptes de l’open source.; Sous-domaines cœur, support et générique
Hit / miss: Un hit trouve la réponse dans le cache. Un miss paie l’appel lent, puis stocke en général le résultat.; Le cache
Hot path (chemin critique): Le code que chaque requête exécute avant de pouvoir répondre. Un appel lent à cet endroit fait attendre l’utilisateur.; Suivre une requête de bout en bout
Hypothèse: Les règles autorisent des hypothèses sur des technologies que tu connais mal, tant que tu les annonces en présentant. Les mauvaises hypothèses, jamais vérifiées avec le client, valent un pouce vers le bas.; Ton premier kata : un design complet en 15 minutes
Idempotent: Le faire deux fois a le même effet que le faire une fois. Passer deux fois un statut à supprimé le laisse supprimé. Ajouter deux fois 10 € à un solde ajoute 20 €.; L’échec : timeouts, retries, idempotence
Image: Un build empaqueté, comme ghcr.io/mastodon/mastodon. La même image peut démarrer plusieurs processus différents, donc une image peut donner plusieurs conteneurs.; Les conteneurs : ce qui tourne vraiment
Interface segregation (I): Ségrégation des interfaces : un appelant ne devrait pas dépendre de méthodes qu’il n’utilise pas. Une interface large force chaque implémentation à remplir des méthodes que personne n’appelle.; SOLID : cinq principes, lus sur du vrai code
Invalidation: Retirer ou rafraîchir une entrée parce que la source a changé. Quelqu’un doit savoir qu’elle a changé.; Le cache
Job asynchrone: L’appelant reçoit une réponse avant que le travail soit fait. Le travail tourne plus tard, depuis une file comme celles de Sidekiq dans Redis, et ses erreurs arrivent par un autre chemin, ou pas du tout.; Appels synchrones ou jobs asynchrones
Kata: Un énoncé d’entraînement : une description, les utilisateurs, les exigences, un peu de contexte en plus. Assez petit pour être esquissé d’une traite.; Ton premier kata : un design complet en 15 minutes
KEP: Kubernetes Enhancement Proposal : le design doc par lequel passe un changement de Kubernetes, avec un template fixe et un statut (provisional, implementable, implemented).; Relire un design : scénarios, portes, pannes
Liskov substitution (L): Substitution de Liskov : toute implémentation d’une interface doit marcher partout où l’interface est attendue. Si une implémentation lève une exception là où les autres marchent, les appelants doivent savoir laquelle ils ont reçue.; SOLID : cinq principes, lus sur du vrai code
Liveness vs readiness: Une probe de liveness en échec fait redémarrer le conteneur par Kubernetes. Une probe de readiness en échec coupe seulement le trafic vers le pod. Un problème de readiness testé dans la liveness redémarre des pods en bonne santé.; Résilience : empêcher une panne de se propager
Mesure de réponse: Le nombre qui tranche entre réussi et raté, par exemple « au plus 25 tentatives par IP en 5 minutes ».; Les scénarios de qualité : rendre « sécurisé » testable
Métriques RED: Pour un service : Rate (requêtes par seconde), Errors (combien échouent), Duration (combien de temps elles prennent).; Observabilité : logs, métriques, traces
Microkernel: Un petit cœur plus des plugins qui ajoutent des fonctionnalités. On dit aussi architecture à plugins.; Les styles d’architecture
Migration post-déploiement: Une migration qui ne tourne qu’une fois que chaque serveur fait tourner le nouveau code. L’étape contract va dans une migration de ce type.; Migrations de schéma et de données
Mode de défaillance: Une façon précise de casser : ce qui tombe, ce que voit l’utilisateur, comment ça se rétablit.; Relire un design : scénarios, portes, pannes
Modérateur: Répond à tes questions en jouant le client, le chef et l’exploitation. Seul, tu écris tes questions à la place.; Ton premier kata : un design complet en 15 minutes
Multi-tenant: Un seul système en marche qui sert plusieurs tenants, au lieu d’une copie par tenant.; Multi-tenant : à qui sont ces données ?
Négociation de capacités: Le serveur liste ce qu’il sait faire, et le client vérifie la liste avant d’utiliser une fonctionnalité. Un même client marche alors avec des serveurs d’âges différents.; Conception et versionnement d’API
Niveau d’isolation: Ce que les tenants partagent : les mêmes tables, le même serveur mais des bases à eux, ou un déploiement à eux. Plus d’isolation coûte plus cher à faire tourner.; Multi-tenant : à qui sont ces données ?
Noisy neighbour: Noisy neighbour (voisin bruyant) : la charge d’un tenant qui ralentit les autres, parce qu’ils partagent du CPU, des workers ou une base de données.; Multi-tenant : à qui sont ces données ?
Open/closed (O): Ouvert/fermé : tu ajoutes du comportement en ajoutant du code, et tu laisses intact le code qui marche. BufferedInputStream en Java ajoute un buffer à n’importe quel InputStream en l’enveloppant, sans toucher aux streams de fichier ou de socket.; SOLID : cinq principes, lus sur du vrai code
Page cache: La mémoire que le système d’exploitation utilise pour garder les données de fichiers lues et écrites récemment. Kafka s’appuie dessus au lieu de construire son propre cache.; Les caractéristiques d’architecture : choisir les trois principales
Partition (shard): Une tranche des données, gardée par un nœud ou un cluster. Chaque ligne vit dans exactement une partition. Répartir les partitions sur plusieurs machines s’appelle le sharding.; Faire grandir les données
Partitionnement technique ou par domaine: Découper le code par couche (controllers, models, jobs) ou par zone métier (topics, sondages, chat). C’est ce qui distingue un monolithe en couches d’un monolithe modulaire.; Les styles d’architecture
Penthouse: L’étage où les gens décident de la stratégie, du budget et des risques. Ils ont besoin de la conséquence, pour pouvoir décider.; Une décision, trois publics
Périmé (stale): La réponse en cache ne correspond plus aux données du propriétaire. Tout cache est périmé de temps en temps, donc tu dois savoir pendant combien de temps et ce que ça casse.; Le cache
Placement par annuaire: Une table de correspondance enregistre où vit chaque clé, au lieu de le calculer avec un hash. Facile d’y ajouter un nœud, mais la table elle-même doit toujours être lisible.; Faire grandir les données
Point de défaillance unique (SPOF): Une seule boîte qui, si elle meurt, emporte tout le service avec elle.; Le déploiement : des boîtes sur des machines
Point de non-retour: L’étape après laquelle tu ne peux plus que corriger en avançant, car revenir en arrière demande une nouvelle migration. Une bonne migration en fait une seule petite étape, le plus tard possible.; Faire évoluer un système en marche sans l’arrêter
Poison message: Un message qui échoue à chaque retry, à cause de données invalides, d’un bug ou d’un champ manquant. Si tu le laisses dans la queue, il la bloque ou tourne en boucle sans fin.; Messaging : files, garanties de livraison et dead letters
Port: Une interface qui appartient au cœur, écrite avec les mots du cœur : upload, download, delete. Elle ne dit rien de la technologie qui se trouve derrière.; Ports et adaptateurs : un seul cœur, plusieurs backends
Porte à double sens: Une décision peu coûteuse à défaire : un flag de configuration, une colonne d’état, une bibliothèque derrière une interface. Décide et avance.; Les décisions réversibles : portes à sens unique et à double sens
Porte à sens unique: Une décision difficile ou impossible à défaire : des données supprimées, un contrat public, des données que tu n’as jamais enregistrées. Ralentis et écris un ADR.; Les décisions réversibles : portes à sens unique et à double sens
Projection (modèle de lecture): Des données dérivées des écritures, façonnées pour un type de lecture. Tu peux la supprimer et la reconstruire depuis la source de vérité.; CQRS et event sourcing
Propriétaire: Le seul service autorisé à écrire une donnée. C’est lui qui fait respecter les règles (invariants) sur cette donnée.; À qui appartiennent les données
Published language: Langage publié : un format partagé et documenté que plusieurs contextes acceptent de parler à la frontière, comme une forme de message que tous les serveurs envoient.; Bounded contexts et context maps
Question bloquante: Une question à laquelle il faut répondre avant d’accepter le design. Marque-la, pour que l’auteur la trouve parmi les petites.; Relire un design : scénarios, portes, pannes
Réconciliation: Un job qui compare les copies plus tard et répare ce qui diffère.; La cohérence entre plusieurs stockages
Redondance: Deux copies ou plus, pour qu’une puisse mourir pendant que les autres continuent. Les copies ne doivent pas dépendre d’une même boîte partagée qui peut mourir aussi.; Le déploiement : des boîtes sur des machines
Référence: Seulement l’id de la donnée de quelqu’un d’autre. Tu n’as rien à synchroniser, mais tu dois demander au propriétaire pour voir le contenu.; À qui appartiennent les données
Règle de dépendance: Ici : l’UI dépend du domaine, et le domaine dépend des données. Aucun import ne remonte, donc la couche la plus basse en sait le moins sur les autres.; Les couches : les imports ne vont que dans un sens
Relais: Le code qui lit les nouvelles lignes de l’outbox et les publie. Il peut interroger la table à intervalles réguliers, ou suivre le journal de la base. Un crash après une publication peut envoyer une ligne deux fois : le relais garantit donc at-least-once.; Outbox et sagas : quand un changement touche deux systèmes
Réplica: Une copie d’une partition sur un autre nœud. Elle ajoute de la capacité de lecture et survit à la perte d’un nœud. Elle n’ajoute aucune capacité d’écriture : chaque écriture va sur chaque copie.; Faire grandir les données
Repository: Dépôt : une interface qui ressemble à une collection d’aggregates. Tu ajoutes, cherches et retires des aggregates entiers, et le code de la base de données reste derrière.; Les briques du DDD : à l’intérieur d’un bounded context
Retry avec backoff: Réessayer en attendant plus longtemps après chaque échec, pour laisser au service en difficulté le temps de récupérer. Le jitter ajoute un peu d’aléatoire à chaque attente, pour que mille clients qui ont échoué ensemble ne réessaient pas tous dans la même seconde.; L’échec : timeouts, retries, idempotence
Revue d’architecture: Lire une proposition pour y trouver les décisions coûteuses à changer, comme un comportement par défaut sur lequel d’autres équipes construisent.; Relire un design : scénarios, portes, pannes
Saga: Un processus réparti sur plusieurs services, où chaque étape est sa propre transaction locale. Si une étape suivante échoue, les étapes précédentes sont annulées par des actions de compensation.; Outbox et sagas : quand un changement touche deux systèmes
Salle des machines: L’étage où vivent le code et l’infrastructure. Les gens qui y sont ont besoin du mécanisme, pour pouvoir construire dessus.; Une décision, trois publics
Saut: Une étape où la requête passe dans une autre partie : une autre couche de code, ou un autre conteneur à travers le réseau, plus lent et qui peut tomber.; Suivre une requête de bout en bout
Scénario: Une phrase testable : qui fait quoi à quelle partie, dans quelle situation, ce que le système doit faire, et comment tu le mesures.; Les scénarios de qualité : rendre « sécurisé » testable
Seam (point de jonction): L’endroit unique qui décide « ancien ou nouveau » pour une requête ou une donnée. Il te le faut avant de pouvoir déplacer quoi que ce soit.; Faire évoluer un système en marche sans l’arrêter
Single responsibility (S): Responsabilité unique : un module a une seule raison de changer, un seul groupe de personnes ou une seule fonctionnalité qui demande des changements. Tu comptes les sources de changement : une classe peut faire plusieurs choses pour une seule source.; SOLID : cinq principes, lus sur du vrai code
Singleton: Une boîte qui doit tourner en un seul exemplaire : tu ne peux pas la rendre redondante en ajoutant une deuxième copie.; Le déploiement : des boîtes sur des machines
SLO: Un objectif sur ce que ressentent les utilisateurs, sur une fenêtre de temps. « 99,5 % des paiements réussissent sur 28 jours. » Les 0,5 % restants sont ton error budget.; Observabilité : logs, métriques, traces
Soft delete (suppression logique): Marquer une ligne comme supprimée (une colonne timestamp) au lieu de la retirer. Les utilisateurs ne la voient plus, et le staff peut encore la restaurer.; Les décisions réversibles : portes à sens unique et à double sens
Source de vérité: Le stockage dont tu gardes les données quand les copies divergent. Tu l’écris en premier et tu reconstruis les autres copies à partir de lui.; La cohérence entre plusieurs stockages
Sous-domaine: Un pan de ce que fait le métier : livrer les posts aux abonnés, connecter les utilisateurs, permettre aux admins de régler des paramètres.; Sous-domaines cœur, support et générique
SSO / fournisseur d’identité: Une seule connexion pour plusieurs applis. Il émet des tokens auxquels les autres services font confiance. Keycloak est un fournisseur d’identité open source très utilisé.; Gateways, tokens et SSO
SSRF: Server-side request forgery. L’attaquant fait récupérer une URL par ton serveur à sa place, et atteint ainsi ce que seul ton serveur peut atteindre.; Modélisation des menaces
Stateless (sans état): Un serveur qui ne garde rien entre les requêtes. N’importe quelle copie peut répondre à n’importe quelle requête, parce que l’état est rangé dans un autre stockage.; L’architecture logicielle : les décisions coûteuses à changer
Stimulus: L’événement qui arrive sur le système : une rafale de connexions, un crash, un pic de trafic.; Les scénarios de qualité : rendre « sécurisé » testable
Strangler fig: Remplacer un système progressivement : le nouveau code pousse autour de l’ancien, prend le relais morceau par morceau, et tu supprimes chaque ancienne partie quand plus rien ne l’utilise (Fowler).; Faire évoluer un système en marche sans l’arrêter
Strategy: Stratégie : plusieurs implémentations interchangeables d’une même interface. L’appelant en choisit une, ou les essaie l’une après l’autre, sans connaître leurs classes.; Design patterns : des formes nommées que tu utilises déjà
STRIDE: Six types de menaces à examiner à chaque passage : Spoofing (usurpation), Tampering (altération), Repudiation (répudiation), Information disclosure (fuite d’information), Denial of service (déni de service), Elevation of privilege (élévation de privilèges).; Modélisation des menaces
Style: La forme globale d’un système : son découpage, sa communication et ses unités de déploiement. Un style a des compromis typiques que tu peux aller vérifier.; Les styles d’architecture
Superseded (remplacé): Le statut d’un ADR qu’un ADR plus récent a remplacé. Tu ne modifies jamais un ADR accepté pour changer la décision : tu en écris un nouveau et tu relies les deux.; Les ADR : écrire le pourquoi d’une décision
Support (supporting): Nécessaire au métier mais sans avantage sur les concurrents. C’est en général simple, donc tu le construis à moindre coût ou tu le sous-traites.; Sous-domaines cœur, support et générique
Système externe: Un système avec lequel tu communiques sans le posséder ni le faire tourner : un fournisseur SSO, un serveur mail, le serveur d’une autre organisation.; Le diagramme de contexte : ton système en une seule boîte
Template method: Patron de méthode : une classe de base fixe les étapes d’un algorithme et laisse une ou plusieurs étapes abstraites. Les sous-classes remplissent les étapes, jamais l’ordre.; Design patterns : des formes nommées que tu utilises déjà
Tenant: Tenant (locataire) : un client dont les données doivent rester séparées de celles des autres. Dans le multisite de Discourse, un tenant est un site, identifié par son nom d’hôte.; Multi-tenant : à qui sont ces données ?
Test de bout en bout: Le système construit, piloté comme le ferait un utilisateur. Lent et large, donc garde-en quelques-uns qui prouvent que les morceaux sont bien câblés ensemble.; Stratégie de test
Test de contrat: Un test qui vérifie une doublure contre la vraie chose qu’elle remplace. Fowler : « These check that all the calls against your test doubles return the same results as a call to the external service would. » (ils vérifient que tous les appels à tes doublures renvoient les mêmes résultats qu’un appel au service externe).; Stratégie de test
Test double (doublure de test): Un remplaçant pour quelque chose avec quoi ton code discute : un stockage en mémoire, une fausse API de paiement, un message écrit à la main. Il rend les tests rapides, et il n’est fidèle que jusqu’à la dernière fois où quelqu’un l’a comparé avec le vrai.; Stratégie de test
Timeout: Le temps que tu attends avant d’abandonner. Il te libère. Il ne te dit rien de ce qui s’est passé de l’autre côté.; L’échec : timeouts, retries, idempotence
Token: Une preuve signée que l’appelant envoie à chaque requête. Un JWT porte ses propres claims, comme qui l’a émis, pour quelle audience, et jusqu’à quand.; Gateways, tokens et SSO
Tolerant reader (lecteur tolérant): Un consommateur qui ne lit que les champs dont il a besoin et ignore le reste. Le fournisseur peut alors ajouter des champs sans demander à personne.; Conception et versionnement d’API
Trace et span: Une trace enregistre le parcours d’une requête à travers tous les services. Un span est une étape de ce parcours, avec un début, une durée, un parent et des attributs.; Observabilité : logs, métriques, traces
Transactional outbox: Enregistre le message dans la même écriture en base que les données. Un relais séparé le lit et le publie vers le broker.; La cohérence entre plusieurs stockages
Transactional outbox: Le service écrit le message sortant dans une table, dans la même transaction que le changement : les deux sont commités, ou aucun des deux. Un relais publie la ligne plus tard.; Outbox et sagas : quand un changement touche deux systèmes
Trust boundary (frontière de confiance): Une ligne sur cette carte où les données passent de quelqu’un à qui tu fais moins confiance à quelqu’un à qui tu fais plus confiance, ou l’inverse. Chaque flèche qui en traverse une est un endroit à examiner.; Modélisation des menaces
TTL: Time to live, durée de vie : combien de temps une entrée reste valable avant d’être jetée. Avec un TTL, personne n’a à retirer l’entrée, c’est l’horloge qui le fait.; Le cache
Value object: Objet valeur : un objet défini uniquement par sa valeur. Il est immuable, comparé par son contenu, et se vérifie lui-même à sa construction. Deux dates qui disent toutes les deux 2026-03-14 sont la même date.; Les briques du DDD : à l’intérieur d’un bounded context
Versions mélangées: Pendant un déploiement progressif, l’ancien et le nouveau code tournent en même temps sur une même base. Chaque état du schéma doit marcher pour les deux.; Migrations de schéma et de données
Vote des pairs: Pouce en haut, « bof » ou en bas. Le pouce en haut ne demande pas des schémas finis, seulement la certitude que tu pourrais les produire avec du temps.; Ton premier kata : un design complet en 15 minutes
Y-statement: Un ADR en une phrase : « Dans le contexte de…, face à…, nous avons choisi… et écarté…, pour obtenir…, en acceptant… »; Les ADR : écrire le pourquoi d’une décision