DDD et agent

Ce que le DDD met au centre : le langage et le métier

Le Domain-Driven Design part d’une idée simple : le logiciel doit refléter le métier, pas l’inverse. Deux niveaux se complètent. Le DDD stratégique découpe le domaine en bounded contexts : des frontières à l’intérieur desquelles un modèle et son vocabulaire ont un sens cohérent. Le DDD tactique, lui, fournit les briques à l’intérieur d’un contexte : entités, value objects, aggregates (et leur racine), repositories.

Point clé : Le DDD n’est pas d’abord une question de technique, mais de langage partagé — aligner les mots des experts métier, des devs et du code.

Le langage ubiquitaire comme prompt naturel

Le langage ubiquitaire (ubiquitous language) est le vocabulaire commun à l’équipe métier et au code. Quand une règle se dit « une commande livrée ne peut plus être annulée », on s’attend à trouver Order, Deliver(), Cancel() dans le code.

Point clé : Quand le code parle déjà le langage métier, le prompt devient presque une phrase métier : « ajoute la règle : une Order en statut Delivered refuse Cancel() ». L’agent n’a pas à deviner ta terminologie.

À l’inverse, un code aux noms génériques (DataManager, process(), flag1) oblige à tout ré-expliquer dans chaque prompt. Le langage ubiquitaire est un contexte gratuit : il vit dans les noms, pas dans la fenêtre de contexte.

Le bounded context comme périmètre de session

Un bounded context délimite un modèle cohérent. C’est aussi un excellent périmètre pour une session d’agent : charger un seul contexte, c’est moins de fichiers, moins de tokens, moins de context rot.

Point clé : Le même mot, deux modèles. Vouloir une seule classe Compte partagée entre les deux contextes crée un couplage qui mélange des règles sans rapport. Chaque contexte garde son modèle.

Attention : un agent qui ne connaît pas tes frontières tendra à fusionner les concepts homonymes « pour éviter la duplication ». La duplication d’un nom entre deux contextes n’est pas du DRY à corriger : c’est une frontière à respecter.

Aggregates et invariants : ce que l’agent ne doit pas casser

Un aggregate regroupe des objets qui changent ensemble, derrière une racine (aggregate root). Toute modification passe par la racine, qui garantit les invariants (ex : le total d’une commande = somme de ses lignes).

Point clé : Un agent qui modifie une entité enfant directement (sans passer par la racine) peut casser un invariant : le code compile, mais l’état devient incohérent.

Garde-fous : exposer des méthodes métier sur la racine (pas des setters publics), encoder les invariants dans des tests, et le rappeler dans le CLAUDE.md. Le test devient la spec exécutable qui attrape la violation.

Les pièges du DDD avec un agent

Attention — modèle anémique. Un agent produit volontiers des classes faites de getters/setters, avec toute la logique dans un service à côté. Le modèle ne protège plus rien : les invariants se dispersent. Remède : demander explicitement un modèle riche (comportements sur les entités) et le montrer par l’exemple.

Attention — sur-modélisation. Tout n’est pas un aggregate avec value objects et events. Pour un CRUD sans règle métier, un modèle simple suffit. Le DDD tactique paie son coût quand il y a de la complexité métier réelle. Simplicité d’abord.

L’agent ne connaît pas tes bounded contexts ni ton langage par défaut. Rends-les visibles : structure de dossiers par contexte, glossaire dans le CLAUDE.md, exemples existants. C’est le meilleur investissement de contexte que tu puisses faire.