Domain-Driven Design

1Knowledge crunching : le modèle naît dans la conversation

Evans ouvre avec une histoire. Il est engagé pour construire un logiciel de conception de circuits imprimés. Problème : il ne connaît rien à l'électronique. Les experts du domaine, des ingénieurs PCB expérimentés, connaissent tout des circuits et rien du code. Les premières réunions sont décourageantes. Evans essaie de comprendre ce que le logiciel doit faire. Les ingénieurs lui décrivent des fichiers ASCII à trier. Ça ne mène nulle part.

Puis il commence à dessiner des diagrammes pendant les conversations. Un "net" (un conducteur qui relie plusieurs composants) devient le premier élément du modèle. Component instance. Pin. Topology. Probe simulation. Chaque conversation raffine le modèle. Evans construit un prototype rapide sans interface et sans persistance, juste du comportement. Les ingénieurs peuvent voir le modèle fonctionner et réagir. La connaissance circule dans les deux sens.

Evans appelle ça le knowledge crunching (littéralement : broyer de la connaissance) : la collaboration continue où développeurs et experts métier tamisent un torrent d'informations pour en distiller un modèle utile aux deux camps. Il identifie cinq ingrédients :

• Ancrer le modèle dans l'implémentation : les classes du code reflètent les concepts du domaine, pas des "Manager" ou "Handler" génériques.
• cultiver une langue commune ;
• développer un modèle riche en connaissance : pas juste un schéma de données ;
• distiller le modèle à mesure que la compréhension grandit ;
• expérimenter en permanence.

Sans ces cinq ingrédients, la connaissance ne traverse pas la table. Elle ruisselle dans un seul sens et ne s'accumule jamais. (ch. 1)

2Ubiquitous Language : une seule langue pour tout le monde

Evans décrit la même conversation sur le routage de cargo deux fois. Le projet : un logiciel qui planifie les itinéraires de cargos maritimes entre les ports du monde. Comment trouver le meilleur itinéraire pour un conteneur entre Shanghai et Rotterdam ? Dans la première version, le développeur parle de "lignes dans la table shipment", d'un "booléen dans l'objet Cargo", de supprimer et régénérer des enregistrements. L'expert du domaine dit "OK, comme vous voulez" à plusieurs reprises. Ils quittent la réunion avec deux compréhensions différentes. Dans la seconde version, les deux parlent d'une "Route Specification", d'un "Itinerary", et d'un "Routing Service qui trouve un Itinerary qui satisfait une Route Specification". La conversation est plus courte, plus précise, sans ambiguïté résiduelle.

La différence, c'est l'Ubiquitous Language (ubiquitous = omniprésent) : un vocabulaire commun unique, utilisé à l'oral, dans les documents, et dans le code lui-même. Quand le code utilise les mêmes mots que l'expert du domaine, un développeur qui le lit comprend son intention sans traduction. Quand les langues divergent (le code dit "row" et l'expert dit "Cargo"), une traduction se produit à chaque réunion, chaque passation, chaque revue de code. Chaque traduction perd quelque chose. Evans résume : « La traduction émousse la communication et appauvrit le knowledge crunching. » (ch. 2)

3Le modèle ET le code forment un seul objet

Le piège classique de l'architecture : l'architecte modélise en réunion, le développeur code ce qu'il peut, et les deux divergent en silence. Evans parle d'un fossé mortel entre l'analyse (comprendre le métier) et la conception (structurer le code) : chaque camp finit par travailler contre l'autre sans le savoir.

La réponse du Model-Driven Design est radicale : le code doit refléter le modèle du domaine de façon littérale. Un objet Commande dans le code correspond à une commande dans le métier, pas à une ligne de table, pas à un DTO, pas à une entité Doctrine taillée pour la base. (Un DTO, Data Transfer Object, est un objet sans comportement dont le seul rôle est de transporter des données. Doctrine, lui, est l'ORM (Object-Relational Mapping) de Symfony qui fait correspondre objets et tables. Ni l'un ni l'autre n'est un modèle.)

La conséquence est concrète : un changement dans le code peut être un changement dans le modèle. Renommer une classe, c'est peut-être changer le vocabulaire du projet. Le code ne décrit plus le modèle de l'extérieur, il l'incarne.

Sans ce lien, les pathologies sont prévisibles. L'architecte qui ne code pas modélise des choses qu'on ne peut pas implémenter. Le développeur isolé code autre chose que ce que le métier voulait.

D'où le principe des Hands-on Modelers (« modélisateurs qui gardent les mains dans le code ») : toute personne qui façonne le modèle doit toucher le code, et tout développeur doit pouvoir parler aux experts du domaine. (ch. 3)

4Entity et Value Object : identité ou valeur ?

Evans a été poursuivi en justice pour des dégâts dans un appartement où il n'avait jamais mis les pieds. La propriétaire avait trouvé son nom dans le bottin téléphonique et supposé qu'il était l'ancien locataire. Deux entrées côte à côte dans un vieux bottin ont prouvé que deux Eric Evans différents habitaient la même ville. L'identité n'est pas dans les attributs. On ne peut pas décider si deux personnes sont la même personne en comparant leur nom et leur adresse. C'est un fil de continuité qui fait qu'un objet reste le même objet dans le temps, même quand ses attributs changent. Evans appelle ces objets des Entities.

Un enfant qui dessine se fiche du marqueur qu'il utilise, tant que la couleur et la pointe sont bonnes. Si on remplace discrètement le marqueur perdu par un identique, le dessin continue sans pause. Le marqueur n'a pas d'identité utile à tracer. Seuls ses attributs comptent. Evans appelle ces objets des Value Objects. Ils sont définis entièrement par leurs attributs, n'ont pas d'identité continue, et doivent être traités comme immuables : si les attributs changent, on crée un nouvel objet plutôt que de modifier l'existant.

La différence devient concrète au moment d'écrire le code, et deux questions la tranchent. Est-ce que je veux suivre cette chose dans le temps, qu'elle reste « la même » même quand ses valeurs changent ? C'est une Entity, comparée par son identité. Ou seules ses valeurs comptent, deux exemplaires identiques étant interchangeables ? C'est un Value Object, comparé attribut par attribut, et remplacé plutôt que modifié. En PHP, le contraste saute aux yeux :

// ENTITY : suivie dans le temps, comparée par IDENTITÉ.
final class Client {
    public function __construct(
        private ClientId $id,            // l'identité, un petit Value Object qui se compare
        private string   $nom,
    ) {}
    public function renommer(string $nom): void {
        $this->nom = $nom;               // on MODIFIE : c'est toujours le client #1042
    }
    public function estLeMemeQue(Client $autre): bool {
        return $this->id->equals($autre->id);   // seul l'id compte, pas le nom
    }
}

// VALUE OBJECT : sans identité, immuable, comparé par VALEUR.
final class Adresse {
    public function __construct(
        public readonly string $rue,
        public readonly string $ville,
    ) {}
    public function avecVille(string $ville): self {
        return new self($this->rue, $ville);     // on REMPLACE : un nouvel objet
    }
    public function estEgaleA(Adresse $autre): bool {
        return $this->rue === $autre->rue
            && $this->ville === $autre->ville;   // TOUS les attributs comptent
    }
}

Et rien n'est gravé : le même objet bascule de l'un à l'autre selon le besoin. Une adresse est un Value Object pour une boutique en ligne, qui veut seulement livrer au bon endroit. La même adresse devient une Entity pour La Poste, qui doit suivre cette boîte aux lettres précise dans le temps. La question n'est jamais « quelle est la nature de cet objet ? » mais « est-ce que mon métier a besoin de le suivre individuellement ? ».

Un Domain Service couvre les opérations qui ne s'intègrent naturellement ni dans un Entity ni dans un Value Object. Un virement bancaire débite un compte et en crédite un autre en appliquant des règles métier. Ni l'un ni l'autre compte n'est le bon foyer pour cette logique. Evans donne trois tests pour reconnaître un Domain Service légitime :

• D'abord, l'opération porte sur un concept qui ne rentre naturellement dans aucun Entity ni Value Object.
• Ensuite, son interface est définie en termes d'autres éléments du modèle domaine.
• Enfin, elle est sans état : n'importe quel client peut appeler n'importe quelle instance sans se soucier de laquelle c'est, comme on appelle une fonction statique.

5Aggregate, Factory, Repository : gérer le cycle de vie

Les objets d'un modèle domaine ne vivent pas isolément. Une voiture a des pneus. Un bon de commande a des lignes. Un compte bancaire a des transactions. Chacun de ces groupements a des règles qui doivent tenir sur l'ensemble du groupe : c'est un Aggregate (agrégat, un groupe d'objets qu'on traite comme un tout). Evans le définit comme un ensemble d'objets manipulé comme une seule unité pour les modifications de données.

Cet ensemble a une racine : un seul Entity que tout ce qui se trouve à l'extérieur de la frontière doit référencer. Les objets internes gardent leurs propres Entities et Value Objects, mais aucun objet extérieur ne peut détenir de référence directe vers eux. La racine est responsable de faire respecter tous les invariants, ces règles qui doivent toujours rester vraies.

L'exemple classique : une voiture dans un logiciel d'atelier de réparation. La voiture est la racine de l'Aggregate, identifiée par son VIN (numéro d'identification du véhicule). Les pneus sont des Entities à l'intérieur de la frontière : ils ont une identité locale (on veut savoir quel pneu est passé sur quelle position), mais pas de signification globale.

Personne n'interroge la base de données pour trouver un pneu précis puis naviguer vers la voiture. On cherche la voiture et on lui demande ses pneus. Si les pneus partent à la déchetterie, leur identité disparaît. Le bloc-moteur, lui, porte un numéro de série traçable indépendamment de la voiture : dans certaines applications, il serait la racine de son propre Aggregate.

Cette frontière n'est pas qu'une protection contre les accès sauvages : c'est l'unité de cohérence du système. D'où la règle d'Evans : une transaction ne modifie qu'un seul aggregate à la fois (une transaction, c'est un groupe de changements qui passent tout ou rien). Si deux aggregates doivent bouger ensemble, par exemple confirmer une Commande et décrémenter le Stock, on ne les enferme pas dans une grosse transaction commune (verrouiller deux bases en même temps est lent et fragile). On valide la Commande, puis on prévient le Stock par un événement asynchrone, traité juste après dans sa propre transaction.

Le bénéfice arrive à grande échelle. Comme aucune transaction ne s'étend sur deux aggregates, chacun peut vivre sur son propre nœud, sa propre base. Les mises à jour entre eux voyagent sous forme d'événements. C'est ce qui rend les systèmes distribués praticables : rien ne verrouille tout d'un coup, chaque aggregate avance de son côté.

La Factory gère le début de la vie d'un objet : assembler un Aggregate complexe à partir de ses pièces, en faisant respecter les invariants dès la création. Evans utilise l'image d'un moteur de voiture : le robot qui l'assemble n'a aucun rôle une fois qu'on conduit. En code, la logique de création vit dans une classe dédiée. La Factory connaît les règles d'assemblage, l'objet fini sait faire son travail, et les deux s'ignorent.

Le Repository gère le milieu et la fin de la vie d'un objet. Il fournit l'illusion d'une collection en mémoire : au lieu d'écrire SELECT * FROM voitures WHERE proprietaire_id = ?, vous appelez $voitureRepo->findByProprietaire($client). La requête SQL disparaît dans le Repository, et votre code pense à des objets, pas à des tables. « Une FACTORY gère le début de la vie d'un objet ; un REPOSITORY aide à gérer le milieu et la fin. » (ch. 6) Sans Repository, Evans a observé que les développeurs recommencent à penser en lignes SQL plutôt qu'en objets domaine, et le modèle se dissout.

Les trois rôles tiennent dans une poignée de lignes. La racine garde son invariant, la Factory livre un objet déjà cohérent, le Repository cache le SQL :

// AGGREGATE : Voiture est la RACINE. Les Pneu vivent DANS sa frontière.
final class Voiture {
    private array $pneus = [];               // Entities internes, jamais exposées
    public function __construct(private Vin $vin) {}

    // le monde extérieur passe TOUJOURS par la racine pour toucher un pneu
    public function changerPneu(Position $pos, Pneu $neuf): void {
        // la racine fait respecter l'invariant (une position = un seul pneu)
        $this->pneus[$pos->value] = $neuf;
    }
}

// FACTORY : assemble un Aggregate complet et déjà cohérent.
final class VoitureFactory {
    public function depuisFiche(FicheAtelier $fiche): Voiture {
        $voiture = new Voiture($fiche->vin());
        foreach ($fiche->pneus() as $pos => $pneu) {
            $voiture->changerPneu($pos, $pneu);
        }
        return $voiture;                      // sort prête à l'emploi, invariants tenus
    }
}

// REPOSITORY : illusion d'une collection en mémoire ; le SQL disparaît.
interface VoitureRepository {
    public function findByProprietaire(Client $client): array;  // au lieu de SELECT * FROM voitures ...
    public function save(Voiture $voiture): void;
}

6Le breakthrough : quand le modèle saute d'un coup

Evans passe des mois sur un logiciel de prêts syndiqués dans une banque d'investissement new-yorkaise. Un prêt syndiqué, c'est un grand prêt (typiquement des dizaines de millions de dollars) co-financé par plusieurs banques : chacune détient une part. L'équipe a introduit un concept qu'elle appelle « Loan Investment » pour désigner la part d'un investisseur dans ce prêt.

Les experts métier disent régulièrement qu'ils ne comprennent pas vraiment ce terme. L'équipe suppose que c'est un problème de langage et continue. Des incohérences d'arrondi apparaissent, le design se complique sans jamais converger.

Puis, en une semaine, tout bascule. L'équipe réalise que « Loan Investment » n'est pas un terme bancaire. C'est quelque chose qu'elle a inventé parce que sa compréhension du domaine était incomplète. Les experts avaient prévenu plusieurs fois. L'équipe avait supposé que le terme servait techniquement. Il ne servait à rien.

Un nouveau concept émerge : le Share Pie. Imaginez un prêt de 100 M$ où la banque A détient 40 % et la banque B 60 %. Le Share Pie représente cette répartition en elle-même, sans la dériver d'un prêt précis. Loan Investment et Loan Adjustment (l'autre concept artificiel inventé en parallèle) disparaissent, et le modèle rétrécit en devenant plus puissant.

Evans l'écrit sans détour : « Notre nouveau modèle marchait bien. Vraiment, vraiment bien. Et on a tous eu l'estomac retourné. » La réaction immédiate à un breakthrough n'est pas l'euphorie, c'est la peur. Trois semaines de refactoring sous deadline serrée, pas de tests automatisés, des parties de l'application temporairement désactivées, un chef de projet courageux qui dit oui. Le conseil habituel (refactoriser en petits pas, garder tout fonctionnel) ne s'applique pas ici. Parfois le refactoring qui compte est celui qu'on ne peut pas faire incrémentalement.

7Bounded Context : le modèle a des frontières

Sur un grand projet, le même mot recouvre des réalités différentes selon qui parle. Dans le CRM (l'outil qui suit la relation commerciale), un « client » a un historique d'achats et des préférences. Dans la facturation, c'est une entité légale identifiée par son numéro d'entreprise (le SIRET). Dans le support, c'est un ticket ouvert avec un niveau de priorité.

Forcer un seul modèle « Client » pour tout le système produit un objet monstrueux qui ne satisfait personne. Pire : quand les modèles se contaminent en silence, on récolte des bugs invisibles, jusqu'au jour où le rapport mensuel plante sur des données incohérentes. Evans en tire une règle : « Unifier totalement le modèle domaine d'un grand système ne sera ni faisable ni rentable. » (ch. 14)

Un Bounded Context est la solution : une frontière explicite à l'intérieur de laquelle un modèle particulier s'applique de façon cohérente. À l'intérieur de la frontière, chaque terme a un seul sens. À l'extérieur, le même mot peut signifier autre chose. C'est acceptable, à condition que la frontière soit explicite. Elle est définie par l'organisation de l'équipe, par la base de code, et par le schéma de base de données.

Garder cette cohérence à l'intérieur d'un contexte demande une discipline qu'Evans appelle Continuous Integration, à ne pas confondre avec les pipelines CI/CD automatisés. C'est une pratique d'équipe. Quand plusieurs personnes codent en parallèle, leurs versions du modèle divergent en silence, chacune affinant « commande » ou « client » dans son coin. On l'empêche en fusionnant souvent, pour que les écarts apparaissent tôt et petits, et en ré-alignant le langage en continu, pour qu'un mot garde un seul sens dans le code comme dans les conversations.

Reste à relier les contextes entre eux : c'est le rôle de la Context Map, un schéma (ou un document) qui nomme chaque Bounded Context du projet et décrit leurs relations. Evans nomme dix patterns pour ces relations :

• Shared Kernel : deux contextes partagent délibérément un sous-ensemble du modèle.
• Customer/Supplier : une équipe dépend formellement d'une autre et pèse sur son planning.
• Anticorruption Layer : une couche de traduction qui empêche un modèle legacy ou externe de contaminer le vôtre.
• Separate Ways : deux parties sans dépendance réelle, qui se développent mieux séparées.

Evans note que « les divergences de modèles sont autant dues à la fragmentation politique et aux priorités managériales divergentes qu'à des préoccupations techniques » : la Context Map est autant un outil organisationnel que technique.

8Core Domain : mettre les meilleurs là où ça compte

Sur un projet décrit par Evans, les développeurs seniors étaient affectés à l'infrastructure base de données et aux couches de messagerie. Du travail techniquement intéressant, transférable sur n'importe quel CV. Le module de gestion des prêts (le cœur réel du business) était confié à un développeur junior. Résultat : « un enchevêtrement incompréhensible. » L'application ne faisait jamais rien de remarquable, quelle que soit l'élégance de l'infrastructure. C'est, selon Evans, un échec systémique dans la façon dont les équipes allouent leur meilleure réflexion.

Le Core Domain est la partie du modèle qui fait la valeur unique de l'application, ce qui la distingue de la concurrence. Chaque système a aussi des Generic Subdomains : des parties que n'importe quelle entreprise du secteur aurait besoin d'avoir, et qui n'apportent aucun avantage concurrentiel. L'authentification, les fuseaux horaires, la comptabilité, les emails transactionnels : tout ça, c'est du Generic Subdomain.

Un plugin WordPress, un SaaS, une librairie npm résolvent ces problèmes mieux que vous ne le feriez vous-même. Les Generic Subdomains sont des candidats légitimes pour des solutions achetées ou des contractants ponctuels. Le Core Domain ne l'est pas. Evans : « Le CORE DOMAIN est l'endroit où la plus grande valeur doit être ajoutée dans votre système. » (ch. 15)

Le Core se noie vite dans la masse du code technique et générique, au point qu'on ne sait plus où il est. Evans propose une échelle de techniques pour le faire ressortir, de la moins chère à la plus coûteuse :

• Domain Vision Statement : une page qui dit ce qu'est le Core et pourquoi il compte, une heure de travail qui aligne l'équipe pour des mois.
• Highlighted Core : le marquer dans le code existant avec des commentaires ou un README, sans rien déplacer.
• Segregated Core : ranger physiquement le cœur dans ses propres modules, à part du code de support.
• Abstract Core : extraire ses interactions essentielles dans des interfaces dont le reste dépend, le geste le plus coûteux.

Chaque marche rend le Core plus visible. Une équipe s'arrête à celle que son budget permet.

9Assessment first : six questions avant la stratégie

Evans ne prescrit pas d'ordre pour appliquer les patterns DDD. Le chapitre 17 ouvre sur un diagnostic : six questions qu'une équipe doit répondre honnêtement avant de décider quoi faire.

• Peut-on dessiner une Context Map cohérente, ou y a-t-il des zones ambiguës où deux équipes utilisent le même mot pour deux choses différentes ?
• L'équipe utilise-t-elle un Ubiquitous Language assez riche (les mots du code et les mots de l'expert sont-ils les mêmes) ?
• Le Core Domain est-il identifié (sait-on où est la valeur unique du système) ?
• La technologie facilite-t-elle ou contrarie-t-elle un Model-Driven Design (l'idée que le code et le modèle domaine évoluent ensemble, en miroir) ?
• Les développeurs ont-ils les compétences techniques pour implémenter un modèle riche ?
• Sont-ils intéressés par le domaine, ou le traitent-ils comme une contrainte à minimiser ?

Les questions ne sont pas rhétoriques. Evans prévient qu'on ne peut pas y répondre à froid : « Vous en savez moins sur ce projet aujourd'hui que vous n'en saurez jamais. » (ch. 17) Comprendre : c'est maintenant que vous en savez le moins, vous ne ferez qu'apprendre. Les grandes décisions d'architecture prises trop tôt sont des paris dans le noir. Les patterns stratégiques ne sont donc pas une recette figée, mais un vocabulaire pour nommer ce qui se passe déjà sur le projet et repérer les moments où l'équipe peut corriger le tir.

Evans referme le livre sur le portrait du genre d'équipe que le DDD finit par façonner : « Ils sont difficiles à satisfaire sur la qualité du modèle domaine, parce qu'ils ne cessent d'en apprendre sur le domaine. Ils voient le raffinement continu comme une opportunité, et un modèle mal ajusté comme un risque. » (Conclusion) Et il termine sur la promesse qui justifie tout le livre : un logiciel qui reste « un plaisir à utiliser et un plaisir à développer », qui ne nous enferme pas à mesure qu'il grandit mais ouvre de nouvelles opportunités et continue à créer de la valeur.