Glossaire

Tous les termes des trois approches, définis simplement et reliés aux articles qui les expliquent en détail.

36 termes

Adaptateur (Adapter): Implémentation technique concrète d'un port : un contrôleur REST, un repository PostgreSQL, un client email. Le domaine ignore lequel est utilisé à un instant donné.
Adaptateurs d'interface (Interface Adapters): Couche de traduction entre le format pratique pour les cas d'usage et le format pratique pour la technologie externe : contrôleurs, présentateurs, mappers.
Agrégat (Aggregate): Groupe d'entités et de value objects qui doivent rester cohérents ensemble à tout instant, avec une racine unique qui garantit les invariants.
Anticorruption Layer (ACL): Couche de traduction construite par un contexte pour se protéger d'un modèle externe qu'il ne veut pas laisser polluer son propre langage métier.
Big Ball of Mud: Système sans frontière ni structure claire, où tout dépend de tout. C'est précisément ce que ports/adaptateurs, cercles et bounded contexts cherchent à éviter.
Bounded Context: Frontière explicite à l'intérieur de laquelle un modèle donné est valide et cohérent. Un même mot ("Client") peut désigner des modèles différents dans des contextes différents.
Cas d'usage (Use Case / Interactor): Orchestration spécifique à l'application ("passer une commande", "annuler un abonnement"). Utilise les entités et définit, via des interfaces, ce dont il a besoin de l'extérieur.
Conformist: Relation de context mapping où un contexte aval accepte tel quel le modèle d'un contexte amont, sans possibilité de négociation.
Context Mapping: Description explicite des relations entre plusieurs bounded contexts : Shared Kernel, Customer/Supplier, Conformist, Anticorruption Layer, Open Host Service.
Couplage et cohésion: Le couplage mesure à quel point deux composants dépendent l'un de l'autre ; la cohésion mesure à quel point les éléments d'un même composant partagent une seule responsabilité claire. Les trois approches visent un couplage faible et une cohésion forte.
Customer / Supplier: Relation où un contexte amont (fournisseur) fournit des données ou services à un contexte aval (client), qui peut influencer sa feuille de route.
Domain Event: Fait qui s'est produit dans le domaine, nommé au passé (OrderPlaced). Permet à d'autres parties du système de réagir sans couplage direct.
Domain Service: Opération métier qui n'appartient naturellement à aucune entité précise, comme transférer un montant entre deux comptes distincts.
Entité (Entity, sens DDD): Objet défini par son identité, qui persiste dans le temps même si ses attributs changent. Une Commande reste la même commande qu'on lui ajoute une ligne.
Entités (cercle Clean Architecture): Le cercle le plus interne : les règles métier les plus générales de l'entreprise, celles qui survivraient à un changement complet d'application.
Event Storming: Atelier collaboratif où développeurs et experts métier posent ensemble, sur des post-its, les événements de domaine pour découvrir le modèle et les bounded contexts.
Factory: Encapsule une logique de création complexe ou soumise à des règles, quand un simple constructeur ne suffit plus à garantir un objet valide.
Frameworks & Drivers: Le cercle le plus externe de Clean Architecture : base de données, framework web, interface utilisateur. Réduit au minimum, essentiellement du câblage.
Gateway: Terme utilisé en Clean Architecture pour désigner une interface définie par un cas d'usage vers l'extérieur - l'équivalent direct d'un port sortant en hexagonale.
Indépendance au framework: Capacité du code métier à fonctionner, être compris et testé sans dépendre d'un framework particulier - un des objectifs partagés par les trois approches.
Inversion de dépendance (Dependency Inversion Principle): Principe SOLID selon lequel les modules de haut niveau ne devraient pas dépendre des modules de bas niveau, mais tous deux d'abstractions. Fondement technique commun à l'hexagonale et à Clean Architecture.
Langage omniprésent (Ubiquitous Language): Vocabulaire précis et partagé entre développeurs et experts métier, utilisé sans traduction, jusque dans le nom des classes et des méthodes du code.
Modèle anémique (Anemic Domain Model): Anti-pattern où les entités ne sont que des sacs de données avec getters/setters, toute la logique métier étant déportée dans des services externes.
Noyau de domaine (Domain core): Le centre de l'hexagone : entités, règles métier, cas d'usage. Il ne dépend d'aucun framework, d'aucune base de données, d'aucune bibliothèque technique.
Onion Architecture: Architecture proposée par Jeffrey Palermo, cousine directe de l'hexagonale et de Clean Architecture : couches concentriques avec dépendances qui pointent vers le centre.
Open Host Service: Contexte qui expose un protocole public bien défini, pensé pour être consommé par plusieurs autres contextes sans coordination individuelle.
Port: Interface définie par le domaine pour communiquer avec l'extérieur, dans un vocabulaire strictement métier. Il en existe deux sortes : entrants (ce que le domaine propose) et sortants (ce dont il a besoin).
Port entrant (Driving / Primary port): Port qui permet à l'extérieur de piloter le domaine : typiquement l'interface d'un cas d'usage, appelée par un contrôleur, une CLI ou un test.
Port sortant (Driven / Secondary port): Port que le domaine définit parce qu'il a besoin de quelque chose de l'extérieur : persister une donnée, envoyer un message. C'est le domaine qui fixe la forme de l'interface.
Présentateur (Presenter): Composant de la couche Adaptateurs d'interface qui met en forme le résultat d'un cas d'usage pour l'affichage, sans porter de règle métier.
Racine d'agrégat (Aggregate Root): Seule entité d'un agrégat accessible depuis l'extérieur. Tout accès aux objets internes de l'agrégat passe obligatoirement par elle.
Règle de dépendance (Dependency Rule): Principe central de Clean Architecture : le code source d'un cercle ne peut référencer que des éléments du même cercle ou d'un cercle plus interne. Jamais l'inverse.
Repository: Donne l'illusion d'une collection en mémoire pour un agrégat donné (save, findById). Correspond toujours à une racine d'agrégat, jamais à une entité interne.
Shared Kernel: Relation de context mapping où deux équipes partagent délibérément une petite portion de modèle commun, avec un coût de coordination assumé.
Testabilité: Facilité avec laquelle une règle métier peut être vérifiée par un test automatisé rapide, sans base de données ni serveur - un des bénéfices directs de l'isolation du domaine.
Value Object (objet-valeur): Objet défini uniquement par ses attributs, sans identité propre, et immuable par construction. Deux Money de "10 EUR" sont interchangeables.