Modéliser la complexité métier, pas la complexité technique

Le problème que ça résout

Il existe deux sortes de complexité dans un logiciel. La complexité accidentelle : celle qu'on s'inflige nous-mêmes (mauvaise architecture, dette technique, outils mal choisis). Et la complexité essentielle : celle qui vient du métier lui-même - les règles de tarification d'un assureur, les contraintes réglementaires d'une banque, la logistique d'un transporteur.

L'architecture hexagonale et Clean Architecture s'attaquent surtout à la première. Le DDD s'attaque à la seconde. Sa thèse : dans un logiciel qui échoue, le problème vient rarement de la technique choisie, mais d'un modèle qui ne correspond pas à la réalité du métier - ou pire, d'une absence totale de modèle explicite.

La réponse d'Evans tient en une idée forte : le code doit être écrit main dans la main avec les experts du domaine, au point que le vocabulaire du code et celui des experts métier deviennent littéralement le même.

Le langage omniprésent (Ubiquitous Language)

Le langage omniprésent est un vocabulaire précis, partagé par les développeurs et les experts métier, utilisé sans traduction ni approximation - dans les discussions, la documentation, et directement dans le nom des classes et des méthodes.

Si les experts métier parlent de "résilier un contrat" et que le code contient une méthode deleteContract(), il y a un problème : soit le code ment sur ce qu'il fait réellement, soit la conversation avec les experts n'a jamais eu lieu. Le bon signal, c'est une méthode terminate() sur une entité Contract, qui applique les règles métier réelles de résiliation (préavis, pénalités, etc.).

Ce langage n'est pas figé : il évolue au fil des conversations, et le code évolue avec lui. C'est un des points les plus sous-estimés du DDD, car il ne demande aucun pattern technique - juste de la discipline dans les mots choisis.

Bounded Context : un modèle n'est valide que dans une frontière explicite

Un mot comme "Client" ne signifie pas la même chose partout dans une entreprise. Dans le contexte des ventes, un client a un historique d'achats et une limite de crédit. Dans le contexte du support, ce même client a des tickets ouverts et un niveau de satisfaction. Vouloir une seule classe Client qui satisfasse ces deux usages mène presque toujours à un modèle bancal, chargé de champs optionnels et de cas particuliers.

Le Bounded Context (contexte borné) est la réponse : on accepte qu'il existe plusieurs modèles du "client", chacun valide et cohérent à l'intérieur de sa propre frontière (le contexte Ventes, le contexte Support), et on gère explicitement la traduction entre ces frontières quand c'est nécessaire.

C'est probablement le concept le plus mal compris du DDD : on l'associe souvent aux microservices, alors qu'un contexte borné peut très bien exister comme un simple module au sein d'un même monolithe. La frontière est avant tout conceptuelle, pas nécessairement une frontière de déploiement.

Context Mapping : organiser les relations entre contextes

Une fois plusieurs contextes bornés identifiés, il faut décrire comment ils communiquent. Evans propose plusieurs patterns de relation, dont voici les plus courants :

Entités et Value Objects

Une Entité est définie 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 ou qu'on change son statut - c'est son identifiant qui compte, pas son état à un instant donné.

Un Value Object (objet-valeur) est défini uniquement par ses attributs, sans identité propre. Deux instances de Money représentant "10 EUR" sont interchangeables et parfaitement égales. Les Value Objects sont immuables par construction : on n'en modifie pas un, on en crée un nouveau.

Cette distinction simple évite un piège courant : représenter une adresse, un prix ou une plage de dates comme une simple chaîne ou un nombre, en dispersant ensuite la logique de validation et de comparaison un peu partout dans le code.

// Value Object : "data class" donne l'égalité par valeur gratuitement
data class Money private constructor(val amount: Int, val currency: String) {

    companion object {
        fun of(amount: Int, currency: String): Money {
            if (amount < 0) throw NegativeAmountError()
            return Money(amount, currency)
        }
    }

    fun add(other: Money): Money {
        assertSameCurrency(other)
        return of(amount + other.amount, currency)
    }

    private fun assertSameCurrency(other: Money) {
        if (currency != other.currency) throw CurrencyMismatchError()
    }
}

Agrégats et racine d'agrégat

Un Agrégat regroupe une ou plusieurs entités et value objects qui doivent rester cohérents ensemble, à tout instant. Une Commande et ses lignes de commande forment un agrégat naturel : on ne peut pas valider une ligne de commande sans passer par les règles de la commande entière (montant minimum, stock disponible, etc.).

L'agrégat a une Racine d'agrégat (Aggregate Root) : la seule entité accessible depuis l'extérieur. Tout accès aux objets internes de l'agrégat passe obligatoirement par la racine, qui garantit ainsi que les invariants sont toujours respectés.

Règle pratique très utile : une transaction ne devrait modifier qu'un seul agrégat à la fois. Si une opération semble devoir toucher deux agrégats en même temps de façon strictement synchrone, c'est souvent le signe que la frontière de l'agrégat est mal tracée - ou qu'un événement de domaine, traité de façon asynchrone, serait plus approprié.

Domain Events, Repositories, Services, Factories

Comment ça s'articule avec l'hexagonale et Clean Architecture

DDD, architecture hexagonale et Clean Architecture ne sont pas des concurrents : ils répondent à des questions différentes. Le DDD répond à "quel modèle mettre dans le cœur du système, et comment le découper en contextes cohérents ?". L'hexagonale et Clean Architecture répondent à "comment protéger ce cœur de tout ce qui l'entoure ?".

En pratique, les entités, value objects et agrégats du DDD sont exactement ce qui vit dans le cercle "Entités" de Clean Architecture, ou dans le noyau de l'architecture hexagonale. Les repositories définis par le domaine sont des ports sortants au sens hexagonal. Les deux approches s'emboîtent naturellement, sans friction.

Pièges fréquents