Glossaire
Le vocabulaire de l’architecture logicielle a un défaut : plusieurs de ses mots les plus employés ont deux ou trois sens différents, et les confusions qui en résultent ne sont pas innocentes — elles conduisent à de mauvaises décisions de conception.
Cette page sert deux usages. Les mots ambigus sont traités d’abord, avec leurs sens distingués un par un. Le reste du vocabulaire suit, groupé par thème, avec un renvoi vers la page qui le développe. Pour une recherche ponctuelle d’un terme précis, la zone de recherche en haut du menu est plus rapide.
Les mots qui portent à confusion
Domaine
Trois sens, dont deux sont couramment mélangés dans une même phrase.
| Sens | Ce que ça désigne | Contexte |
|---|---|---|
| L’activité | Ce que fait l’entreprise : la billetterie, le transport, l’assurance | DDD — l’espace du problème |
| La couche | L’endroit du code où vivent les règles métier, sans dépendance technique | N-Tiers, hexagonal |
| Le modèle | L’ensemble des objets qui représentent l’activité — « le domaine contient trois agrégats » | DDD tactique |
Le premier existe indépendamment de tout logiciel : personne ne le décide, on le constate. Les deux autres sont des choix de conception. Dire « il faut mettre ça dans le domaine » emploie le deuxième sens ; dire « notre domaine est complexe » emploie le premier. Les distinguer évite de croire qu’on discute d’architecture alors qu’on discute de métier, ou l’inverse.
Entité
Le mot le plus surchargé de la section, avec trois sens qui n’ont presque rien en commun.
| Sens | Définition | Reconnaissable à |
|---|---|---|
| Entité DDD | Un objet défini par son identité, qui persiste à travers ses changements d’état, et qui porte du comportement | Des méthodes au nom métier : confirmer(), suspendre() |
| Entité ORM | Une classe mappée à une table de base de données | Une annotation : @Entity, Base, #[derive(FromRow)] |
| Entité, au sens large | N’importe quel objet métier, n’importe quel nom du domaine | Usage courant, sans définition précise |
La confusion coûteuse est entre les deux premiers. Ils peuvent coïncider — un même objet jouant les deux rôles — mais leurs exigences sont opposées : l’ORM demande un constructeur sans argument, des champs mutables et des accesseurs publics ; l’entité DDD demande l’inverse, puisque son travail est d’interdire les états invalides.
Un projet qui parle d’« entités » sans préciser laquelle finit régulièrement avec des classes annotées, sans comportement, appelées entités par tout le monde — c’est-à-dire un modèle anémique.
Voir Entités et objets valeur.
Service
Quatre sens, et il est fréquent d’en croiser trois dans la même conversation.
| Sens | Rôle | Contient |
|---|---|---|
| Service de domaine | Une règle métier qui croise plusieurs agrégats | De la logique métier pure |
| Service applicatif (cas d’usage) | Orchestrer : charger, appeler, sauvegarder, publier | Aucune règle métier |
| La couche service du 3-tier | La strate entre contrôleur et dépôt | Règles et orchestration mélangées |
| Un service au sens déploiement | Un processus déployé séparément — un microservice | Ce qu’on veut |
Le troisième sens est celui qui pose problème : en confondant règles et orchestration dans une seule couche, il crée le point de départ de plusieurs pathologies décrites dans N-Tiers. La distinction entre les deux premiers est détaillée dans Services, dépôts et fabriques.
Conteneur
| Sens | Définition |
|---|---|
| Conteneur C4 | Une unité exécutable ou déployable qui héberge du code ou des données : une application web, une API, une base de données, une file de messages |
| Conteneur Docker | Un mécanisme d’empaquetage et d’isolation d’un processus |
Une base de données PostgreSQL est un conteneur C4 et n’est pas un conteneur Docker ; un sidecar de collecte de journaux est un conteneur Docker et n’est pas un conteneur C4. Voir C4 Model.
Composant
| Sens | Définition |
|---|---|
| Composant C4 | Un regroupement de code derrière une interface, à l’intérieur d’un conteneur, non déployable seul |
| Composant de framework | Une unité d’interface utilisateur — un composant Angular, React, Vue |
| Composant, au sens large | Un morceau de logiciel réutilisable |
Inversion et injection de dépendances
Deux notions distinctes que la proximité des noms fait confondre en permanence.
| Nature | Question | |
|---|---|---|
| Inversion des dépendances | Un principe de conception | Qui déclare l’interface : celui qui l’utilise, ou celui qui l’implémente ? |
| Injection de dépendances | Une technique de câblage | Qui fournit l’implémentation concrète : l’objet lui-même, ou quelqu’un d’autre ? |
On peut injecter sans rien inverser — passer une classe concrète au constructeur respecte l’injection et ne renverse aucune dépendance. L’inversion suppose que l’interface appartienne au module de haut niveau, ce qui est le point difficile. Voir SOLID.
Le métier, et ce qui n’en est pas
Le mot métier désigne trois choses à la fois, et c’est acceptable parce qu’elles sont liées : l’activité de l’entreprise, les règles qui la gouvernent, et les personnes qui les connaissent. « Demander au métier » veut dire aller voir ces personnes ; « une règle métier » désigne une contrainte issue de cette activité ; « le métier est complexe » parle de l’activité elle-même.
Ce qui compte est la frontière avec la technique. Un test simple et fiable :
Une règle métier peut être énoncée sans nommer aucune technologie, et un expert du domaine peut dire si elle est vraie ou fausse.
« Une commande de plus de 1 000 € exige une validation du client » est une règle
métier : aucune technologie n’y figure, et le service commercial peut la confirmer.
« La requête doit utiliser un index sur client_id » est une contrainte technique :
personne au commerce ne peut se prononcer.
Cette frontière est l’objet de presque toute la section. Le métier est la partie stable et précieuse — les règles de facturation valent dix ans ; la technique est la partie volatile — le choix de la base de données change trois fois dans l’intervalle. Presque toutes les décisions d’architecture discutées ici reviennent à empêcher la seconde de contaminer la première.
Le métier et son modèle
| Terme | Définition | Page |
|---|---|---|
| Métier | L’activité de l’entreprise, ses règles, et les gens qui les connaissent | — |
| Domaine (domain) | L’activité que le logiciel prend en charge | Sous-domaines |
| Sous-domaine (subdomain) | Une partie distincte du domaine — cœur, support ou génerique | Sous-domaines |
| Cœur de métier (core domain) | Le sous-domaine qui distingue l’entreprise de ses concurrents | Sous-domaines |
| Modèle (model) | Une simplification volontaire du domaine, retenue parce qu’elle est utile — pas parce qu’elle est fidèle | DDD |
| Règle métier (business rule) | Une contrainte énonçable sans technologie et vérifiable par un expert | — |
| Invariant | Une règle vraie à chaque instant, sans délai ni exception | Agrégats |
| Expert du domaine (domain expert) | La personne qui connaît le métier et peut arbitrer un cas limite | Langage omniprésent |
| Langage omniprésent (ubiquitous language) | Un vocabulaire unique, du métier jusqu’aux noms de méthodes | Langage omniprésent |
| Contexte délimité (bounded context) | La frontière à l’intérieur de laquelle un mot a exactement un sens | Contextes délimités |
| Cas d’usage (use case) | Une chose que l’application sait faire, du point de vue de celui qui la déclenche | Hexagonal |
| CRUD | Create, Read, Update, Delete — une application qui déplace des données sans en décider | N-Tiers |
Les objets du modèle
| Terme | Définition | Page |
|---|---|---|
| Objet valeur (value object) | Défini par ses attributs, immuable, sans identité — deux montants égaux sont le même montant | Entités et objets valeur |
| Entité (entity) | Définie par son identité, qui persiste à travers ses changements d’état | Entités et objets valeur |
| Agrégat (aggregate) | Un groupe d’objets traité comme une unité de cohérence, donc de transaction | Agrégats |
| Racine d’agrégat (aggregate root) | L’entité par laquelle on accède à l’agrégat — le seul point d’entrée | Agrégats |
| Dépôt (repository) | L’illusion d’une collection en mémoire d’agrégats ; un par racine | Services et dépôts |
| DAO (data access object) | Un objet d’accès aux données, orienté table et non agrégat — à ne pas confondre avec un dépôt | Services et dépôts |
| Fabrique (factory) | Encapsule une construction complexe, ou la reconstitution depuis la persistance | Services et dépôts |
| DTO (data transfer object) | Une structure sans comportement, dédiée au transport à une frontière — ni entité, ni objet valeur | N-Tiers |
| Événement de domaine (domain event) | Un fait métier survenu, immuable, nommé au passé | Événements |
| Événement d’intégration (integration event) | Le même fait, traduit en contrat stable pour l’extérieur | Événements |
| Modèle anémique (anemic domain model) | Des objets réduits à des accesseurs, et des services qui font tout le travail | Mise en œuvre |
| Obsession des primitifs (primitive obsession) | Décrire un domaine avec des string et des number, donc sans règles | Entités et objets valeur |
La structure du code
| Terme | Définition | Page |
|---|---|---|
| Couche (layer) | Un regroupement logique de code | N-Tiers |
| Étage (tier) | Une unité de déploiement physique | N-Tiers |
| 3-tier | Contrôleur, service, dépôt — la forme dominante de l’architecture en couches | N-Tiers |
| Port | Une interface déclarée par le domaine : ce qu’il offre, ou ce dont il a besoin | Hexagonal |
| Adaptateur (adapter) | L’implémentation qui relie un port au monde réel | Hexagonal |
| Règle de dépendance (dependency rule) | Toute dépendance du code source pointe vers l’intérieur | Hexagonal |
| Racine de composition (composition root) | Le seul endroit qui connaît toutes les implémentations concrètes | Hexagonal |
| Couche d’anticorruption (anticorruption layer) | La traduction qui empêche le modèle d’un voisin de contaminer le sien | Cartographie |
| Noyau partagé (shared kernel) | Le peu de modèle que deux contextes détiennent en commun | Cartographie |
| Monolithe modulaire | Un seul déploiement, mais des frontières de modèle réelles et vérifiées à l’intérieur | Monolithe, modulaire, microservices |
| Monolithe distribué | Plusieurs services qui partagent un modèle ou une base : le couplage du monolithe, avec les pannes du distribué | Monolithe, modulaire, microservices |
| API de module | La seule surface publique d’un module ; tout le reste est inaccessible | Monolithe, modulaire, microservices |
| Nano-service | Un service découpé plus fin qu’un contexte — un par entité ou par table | Monolithe, modulaire, microservices |
| Grande boule de boue (big ball of mud) | Une zone sans structure discernable ; on l’entoure d’une frontière, on ne la modélise pas | Cartographie |
| Système hérité (legacy) | Un système qu’on ne peut pas modifier librement, et dont il faut se protéger | Cartographie |
| Étranglement progressif (strangler fig) | Remplacer un système en détournant ses usages un par un, plutôt qu’en le réécrivant | Mise en œuvre |
Les dépendances
| Terme | Définition | Page |
|---|---|---|
| Couplage (coupling) | La mesure de ce qui doit changer ailleurs quand on change ici | Couplage et cohésion |
| Cohésion (cohesion) | La mesure de ce qui, dans un module, change pour les mêmes raisons | Couplage et cohésion |
| Connascence (connascence) | Le couplage gradué sur trois dimensions : force, degré, localité | Couplage et cohésion |
| Module profond / superficiel | Beaucoup de fonctionnalité derrière une interface étroite — ou l’inverse | Couplage et cohésion |
| Dissimulation d’information (information hiding) | Un module cache une décision susceptible de changer | Couplage et cohésion |
| Amont / aval (upstream / downstream) | Qui influence, qui subit — indépendamment du sens des appels | Cartographie |
| Abstraction | Un nom qui masque plusieurs réalisations possibles | SOLID |
| Indirection | Un niveau de plus à traverser pour lire le code. Toute abstraction en crée une ; l’inverse est faux | SOLID |
| Injection de dépendances | Fournir à un objet ses collaborateurs depuis l’extérieur | SOLID |
| Inversion des dépendances | Faire dépendre le concret de l’abstrait, l’interface appartenant au module de haut niveau | SOLID |
| Loi de Conway | Un système finit par refléter la structure de communication de l’organisation qui le produit | Cartographie |
La cohérence et les transactions
| Terme | Définition | Page |
|---|---|---|
| Transaction | Un ensemble d’écritures validé ou annulé d’un bloc | Agrégats |
| Frontière de cohérence | L’étendue de ce qui doit être cohérent à chaque instant — c’est-à-dire un agrégat | Agrégats |
| Cohérence différée (eventual consistency) | Deux choses d’accord un peu plus tard, ce qui est une décision métier et non technique | Agrégats |
| Verrou optimiste (optimistic locking) | Détecter les modifications concurrentes par un numéro de version, plutôt que les empêcher | Agrégats |
| Idempotence | Traiter deux fois le même message a le même effet que le traiter une fois | Événements |
| CQRS | Séparer le modèle qui décide de celui qui affiche | CQRS et Event sourcing |
| Event sourcing | Stocker la suite des faits plutôt que l’état courant ; l’état devient un calcul | CQRS et Event sourcing |
| Projection | Un modèle de lecture construit depuis un flux d’événements, reconstructible | CQRS et Event sourcing |
| Commande / requête | Une commande change l’état sans rien renvoyer ; une requête renvoie sans rien changer | CQRS et Event sourcing |
| Instantané (snapshot) | Un état sauvegardé pour éviter de rejouer tout un flux d’événements | CQRS et Event sourcing |
| Compensation | Corriger un fait par un fait inverse, faute de pouvoir annuler | CQRS et Event sourcing |
| Patron outbox (transactional outbox) | Écrire l’événement dans la même transaction que la donnée, et le publier ensuite | Événements |
| Au moins une fois (at-least-once) | La garantie de livraison réellement atteignable ; « exactement une fois » n’existe pas | Événements |
La résilience et la panne
| Terme | Définition | Page |
|---|---|---|
| Panne partielle | Dans un système distribué, l’état normal : une partie répond, une autre non | Patrons de résilience |
| Défaillance en cascade (cascading failure) | Une dépendance lente épuise les ressources de son appelant, qui tombe à son tour | Patrons de résilience |
| Délai d’attente (timeout) | La borne au-delà de laquelle on abandonne un appel. Le patron numéro un | Patrons de résilience |
| Reprise (retry) | Réessayer un appel échoué — uniquement si l’opération est idempotente | Patrons de résilience |
| Recul exponentiel (exponential backoff) | Attendre de plus en plus longtemps entre deux tentatives | Patrons de résilience |
| Gigue (jitter) | L’aléa ajouté au recul, qui empêche tous les clients de réessayer ensemble | Patrons de résilience |
| Tempête de reprises (retry storm) | Des reprises synchronisées qui achèvent un service en cours de rétablissement | Patrons de résilience |
| Disjoncteur (circuit breaker) | Échouer vite après un seuil d’échecs, pour libérer l’appelant | Patrons de résilience |
| Cloisonnement (bulkhead) | Un pool de ressources par dépendance, pour qu’une seule n’en prive pas les autres | Patrons de résilience |
| Dégradation gracieuse | Répondre partiellement plutôt que pas du tout | Patrons de résilience |
| Repli (fallback) | La valeur de secours — à signaler comme telle, jamais silencieuse | Patrons de résilience |
| Délestage (load shedding) | Refuser tôt une partie du trafic pour servir correctement le reste | Patrons de résilience |
| Limitation de débit (rate limiting) | Borner ce qu’un client donné peut consommer | Patrons de résilience |
| Contre-pression (backpressure) | Faire remonter la saturation à l’appelant, au lieu d’empiler dans une file | Patrons de résilience |
Patrons, principes et pratiques
Trois natures différentes, souvent rangées ensemble à tort.
| Nature | Ce que c’est | Comment on s’en sert |
|---|---|---|
| Principe | Une direction, sans mise en œuvre imposée — SOLID, la règle de dépendance | On s’en sert pour arbitrer |
| Patron (pattern) | Une solution nommée à un problème récurrent — Adapter, Observer | On s’en sert pour nommer une solution vers laquelle le problème mène déjà |
| Anti-patron | Une solution répandue dont on connaît les dégâts — modèle anémique, monolithe distribué | On s’en sert pour diagnostiquer |
| Idiome | Une tournure propre à un langage — Option en Rust, les générateurs en Python | On s’en sert par habitude du langage |
| Pratique | Une activité — event storming, revue de code, tests d’architecture | On la fait |
| Terme | Définition | Page |
|---|---|---|
| Patron de conception (design pattern) | Une solution nommée à un problème de conception récurrent | Design patterns |
| Gang of Four | Les quatre auteurs du catalogue de 1994 ; par extension, ses 23 patrons | Design patterns |
| SOLID | Cinq principes de conception à l’échelle de la classe et du module | SOLID |
| Event storming | Un atelier qui reconstitue un métier comme une suite d’événements | Event storming |
| Tests d’architecture (fitness functions) | Des tests automatisés qui font échouer la CI si une frontière est franchie | Tests d’architecture |
| Fonction d’aptitude (fitness function) | Une caractéristique architecturale rendue exécutable | Tests d’architecture |
| Cliquet (ratchet) | Tolérer les violations existantes, interdire les nouvelles, abaisser le seuil | Tests d’architecture |
Documenter
| Terme | Définition | Page |
|---|---|---|
| Vitesse de péremption | Le critère de classement : immuable, dérivé, généré, ou entretenu — seul le dernier pourrit | Documenter une architecture |
| Architecture-as-code | Tout artefact d’architecture vit dans le dépôt, en texte, versionné avec le code | Documenter une architecture |
| Docs-as-code | La documentation suit le cycle de vie du code : même dépôt, même revue | Documenter une architecture |
| Diátaxis | Quatre formes qui ne se mélangent pas : tutoriel, guide pratique, référence, explication | Documenter une architecture |
| arc42 | Douze chapitres pour décrire une architecture — une liste de questions, pas un formulaire | Documenter une architecture |
| Modèle 4+1 | L’ancêtre : quatre vues plus les scénarios, sans niveaux d’abstraction fixés | Documenter une architecture |
| Contrat (OpenAPI, AsyncAPI) | La documentation exécutable d’une interface : une forme, jamais un sens | Documenter une architecture |
| Test de contrat | Vérifier automatiquement qu’un producteur et ses consommateurs restent compatibles | Tests d’architecture |
| Dérive (drift) | L’écart entre le modèle décrit et le système réellement déployé | Documenter une architecture |
| Trace distribuée | Le graphe d’appels réel, reconstitué depuis la production — et souvent différent du modèle | Documenter une architecture |
| ADR (architecture decision record) | Un fichier par décision : contexte, options, choix, conséquences — journalisé, jamais mis à jour | ADR |
Le vocabulaire des diagrammes
| Terme | Définition | Page |
|---|---|---|
| C4 | Quatre niveaux de zoom : contexte, conteneurs, composants, code | C4 Model |
| Personne (person) | Un utilisateur humain, dans un rôle | C4 Model |
| Système logiciel (software system) | La plus grande unité livrable, celle dont quelqu’un est responsable | C4 Model |
| Conteneur C4 (container) | Une unité exécutable ou déployable qui héberge du code ou des données | C4 Model |
| Composant C4 (component) | Un regroupement de code derrière une interface, dans un conteneur | C4 Model |
| Workspace | Chez Structurizr, le modèle et ses vues réunis | Structurizr |
| Vue (view) | Une projection du modèle : ce qu’on choisit de montrer | Vues et styles |
| UML | Quatorze types de diagrammes, dont trois valent d’être connus | UML |
| Diagramme de séquence | Qui appelle qui, dans quel ordre, en synchrone ou en asynchrone | UML |
| Diagramme d’états | Un cycle de vie, et surtout les transitions qui n’existent pas | UML |
| Multiplicité | 1, 0..1, *, 1..* aux extrémités d’une relation — souvent un invariant métier | UML |
Trois distinctions à retenir
Si une seule chose doit rester de cette page, ce sont ces trois oppositions — elles reviennent dans presque toutes les décisions de la section.
Métier contre technique. Le premier est stable et précieux, le second volatile. Toute l’architecture consiste à empêcher le second de contaminer le premier.
Problème contre solution. Le domaine et ses sous-domaines sont constatés ; les contextes délimités, les couches et les services sont décidés. Confondre les deux fait débattre de découpage technique quand la question est de savoir de quoi l’entreprise s’occupe.
Immédiat contre différé. Ce qui doit être vrai à chaque instant définit une frontière de transaction ; tout le reste peut attendre. C’est cette question, posée à l’expert du domaine et non à l’équipe technique, qui détermine la forme du modèle.