11 - Glossaire complet
Ce que tu vas trouver ici
Tous les termes techniques utilises dans ce cours, classes par ordre alphabetique. Chaque terme a une définition courte et un exemple concret.
Prerequisites
Ce glossaire est conçu pour etre consulte a tout moment. Il est plus utile apres avoir lu les articles précédents.
Aggregate
Un regroupement d'entités et de Value Objects traites comme une unité. L'Aggregate a une entité "racine" qui contrôle l'acces aux autres. On ne modifie jamais un sous-objet directement, on passe toujours par la racine.
Exemple : une Place (racine) contient des ImageAsset et des Translation. On ne modifie pas une Translation directement, on passe par Place.updateTranslation().
Audit Trail
L'historique complet des actions effectuees sur une entité : qui a fait quoi, quand, depuis quel état, vers quel état. Indispensable pour le debug et la conformité.
Exemple : { entity: "place_42", from: "ENRICHED", to: "READY_FOR_IMAGES", by: "user_123", at: "2026-03-28T10:00:00Z" }.
Bounded Context
En DDD, un perimetre au sein duquel un modèle de domaine est valide. En dehors de ce perimetre, les memes mots peuvent avoir un sens différent. Chaque Bounded Context a son propre vocabulaire et ses propres regles.
Exemple : "Place" dans le contexte "Cycle de vie" = un lieu en cours de création. "Place" dans le contexte "Analytics" = un lieu avec des statistiques de consultation.
CQRS (Command Query Responsibility Segregation)
Un pattern qui séparé les opérations de lecture (Query) et d'écriture (Command) en deux modèles distincts. Les ecritures passent par le domaine (transitions, guards). Les lectures peuvent utiliser des projections optimisees.
Exemple : écrire sur une Place (changer son état) passe par la state machine. Lire une Place pour l'afficher peut utiliser une vue materialisee optimisee pour la lecture.
Domain (Domaine métier)
Un perimetre fonctionnel coherent du logiciel, avec son vocabulaire, ses invariants, et ses regles de cycle de vie. C'est le contrat le plus eleve du système.
Exemple : "Cycle de vie Place" -- tout ce qui concerne l'évolution d'un lieu touristique de sa création a sa publication. Voir article 01.
Domain Event
Un fait qui s'est produit dans le domaine, exprime au passe. Il est immutable (on ne modifie jamais un événement passe) et peut etre consomme par d'autres parties du système.
Exemple : PlacePublished { placeId: "place_42", publishedAt: "2026-03-28T14:00:00Z" }.
DTO (Data Transfer Object)
Un objet qui sert uniquement a transporter des donnees entre deux couches du système. Pas de logique métier, pas de cycle de vie, pas d'identité.
Exemple : CreatePlaceDTO { name: "Cafe de Flore", latitude: 48.85, longitude: 2.33 }. Voir article 02.
Entity (Entité)
Un objet métier avec une identité persistante (un id). Meme si ses attributs changent, c'est toujours la meme entité. Elle a un cycle de vie et des invariants.
Exemple : Place { id: "place_42", name: "Cafe de Flore", status: "ENRICHED" }. Voir article 02.
Event Sourcing
Un pattern ou on ne stocke pas l'état courant d'une entité, mais la sequence de tous les événements qui ont mene a cet état. On peut reconstruire l'état a n'importe quel moment en rejouant les événements.
Exemple : au lieu de status: "PUBLISHED", on a : [PlaceCreated, PlaceEnriched, ImagesProcessed, ImagesValidated, PlacePublished]. L'état courant est le résultat de la lecture de tous ces événements.
FSM (Finite State Machine / Machine a états finis)
Un modèle formel definissant des états finis, des transitions entre eux, des guards, et des side effects. C'est la formalisation d'un cycle de vie.
Exemple : voir article 04.
Guard (Garde)
Une precondition a vérifier avant d'autoriser une transition. C'est une fonction pure qui retourne vrai ou faux.
Exemple : canPublish(place) = place.images.length >= 3 && place.translations.every(t => t.description !== null). Voir article 05.
Idempotence
Propriété d'une opération qui, exécutée plusieurs fois, produit le meme résultat qu'une seule exécution. Essentiel pour les retries et les systèmes distribues.
Exemple : transitionner une Place deja PUBLISHED vers PUBLISHED = no-op, pas une erreur. Voir article 08.
Invariant
Une condition qui doit toujours etre vraie quand une entité est dans un état donne. Testable, binaire, independant de l'implementation.
Exemple : "Une Place en PUBLISHED a au moins 3 URL d'image valide." Voir article 07.
Lifecycle (Cycle de vie)
La suite ordonnee d'états qu'une entité traverse de sa création a sa forme finale. C'est l'ossature d'un domaine.
Exemple : DRAFT -> ENRICHED -> READY_FOR_IMAGES -> IMAGES_PROCESSING -> IMAGES_PROCESSED -> READY_FOR_PUBLICATION -> PUBLISHED. Voir article 03.
Side Effect (Effet de bord)
Une action déclenchée par une transition : envoi d'email, mise à jour de cache, log, notification. Se produit apres le changement d'état.
Exemple : quand une Place passe a PUBLISHED, envoyer une notification et invalider le cache. Voir article 05.
Single Source of Truth (SSOT / Source unique de vérité)
Principe selon lequel l'état d'une entité doit etre stocke a un seul endroit, autoritaire et consultable par tous les systèmes.
Exemple : PostgreSQL est la SSOT pour le status des Places. Si Redis dit DRAFT et PostgreSQL dit ENRICHED, PostgreSQL a raison. Voir article 06.
State Machine (Machine a états)
Synonyme de FSM. Voir FSM ci-dessus.
Transition
Le passage d'un état A a un état B. Explicite, contrainte, atomique, auditable.
Exemple : ENRICHED -> READY_FOR_IMAGES déclenchée par l'événement REQUEST_IMAGES. Voir article 05.
Ubiquitous Language (Langage ubiquitaire)
En DDD, le vocabulaire partage entre les développeurs et les experts métier. Chaque terme a un sens unique, utilise de facon coherente dans le code, la documentation, et les conversations.
Exemple : si on dit "Place", tout le monde (dev, product, ops) comprend la meme chose. On ne dit pas "lieu" dans le code et "Place" dans les specs.
Value Object (Objet-valeur)
Un objet défini entièrement par ses attributs, sans identité propre. Deux Value Objects avec les memes attributs sont identiques et interchangeables. Immutable.
Exemple : Address { street: "12 rue de Rivoli", city: "Paris", zipCode: "75001" }. Voir article 02.
Article précédent : 10 - Features vs Domaine
Fin du cours. Tu as maintenant les bases pour structurer un domaine, définir un cycle de vie, et éviter les pièges classiques de la dette technique. Pour voir ces concepts appliques a un vrai projet, jette un oeil a paltemps.fr. Bonne route, piou piou.