Conception stratégique pilotée par le domaine : contextes délimités et cartes de contextes

Pourquoi la conception pilotée par le domaine a sa place dans un chapitre sur la structure

Chaque style de ce chapitre a besoin de frontières. Un monolithe modulaire a besoin de frontières entre modules ; les microservices du chapitre 6 ont besoin de frontières entre services ; même une application hexagonale doit savoir ce qui a sa place à l’intérieur de l’hexagone. La conception pilotée par le domaine (DDD) est la méthode la plus utilisée pour trouver ces frontières dans le domaine métier lui-même, plutôt que dans des couches techniques.

Eric Evans l’a présentée dans Domain-Driven Design: Tackling Complexity in the Heart of Software (Addison-Wesley, 2003). Selon lui, dans la plupart des logiciels de gestion, les problèmes les plus difficiles ne sont pas techniques : ils tiennent à la compréhension du domaine, c’est-à-dire à ce qu’est vraiment un contrat d’assurance, un sinistre, une livraison ou un remboursement, et aux règles qui les régissent. Le logiciel devrait donc être construit autour d’un modèle du domaine conçu délibérément, élaboré conjointement par les développeurs et les experts du domaine, et ce modèle devrait être protégé de toute confusion avec d’autres modèles. En 2015, Evans a publié une courte DDD Reference qui résume les patrons et en ajoute quelques-uns, comme le partenariat et la grosse boule de boue (big ball of mud) en tant que patrons de carte de contextes, et les événements de domaine en tant que bloc de construction.

La DDD comporte deux volets. La conception stratégique divise un grand domaine en sous-domaines et en contextes délimités, et cartographie les relations entre eux ; c’est de l’architecture, et c’est le sujet principal ici. La conception tactique fournit des blocs de construction (entités, objets valeur, agrégats et autres) pour écrire le modèle à l’intérieur d’un contexte ; c’est de la conception, et elle est traitée brièvement.

Langage omniprésent (ubiquitous language)

Un langage omniprésent (ubiquitous language) est un vocabulaire partagé, construit ensemble par les développeurs et les experts du domaine, et employé de manière cohérente dans les conversations, les documents, les tests et le code. Si les répartiteurs disent qu’un livreur est « empilé » lorsqu’il transporte deux commandes du même restaurant, alors le code dit stack, et non multiOrderAssignment. Quand un terme se révèle ambigu ou maladroit, l’équipe change le langage et le code en même temps.

Cela ressemble à une simple question de nommage, mais les conséquences sont architecturales. C’est dans la traduction entre les mots du métier et les mots du code que naissent les malentendus, et donc les défauts. Et dès que deux groupes emploient le même mot avec des sens différents, vous tenez la preuve de l’existence de deux modèles différents, ce qui est le point de départ des contextes délimités.

Les sous-domaines : cœur, de soutien et génériques

Le domaine métier dans son ensemble se divise en sous-domaines : des domaines d’activité comme les cartes, les commandes, les paiements et l’affectation des livreurs. Les praticiens les classent en trois catégories, en s’appuyant sur la distinction d’Evans entre le domaine cœur et les sous-domaines génériques ; la répartition en trois, avec les sous-domaines de soutien, a été popularisée par des auteurs ultérieurs, notamment Vaughn Vernon dans Implementing Domain-Driven Design (2013).

Le domaine cœur (core domain) est ce qui distingue l’entreprise de ses concurrents et la raison pour laquelle le logiciel vaut la peine d’être construit. Pour une entreprise de livraison de repas, c’est probablement l’affectation : associer les commandes aux livreurs et prédire les heures d’arrivée. Un sous-domaine de soutien (supporting subdomain) est propre à l’entreprise et nécessaire, mais n’est pas une source d’avantage : la gestion des cartes, l’intégration des livreurs. Un sous-domaine générique est un problème que partagent de nombreuses entreprises, pour lequel il existe de bonnes solutions : les paiements, l’identité, l’e-mail et les SMS.

Ce classement est une décision d’investissement. Le cœur mérite les personnes les plus expérimentées, la modélisation la plus riche et du code que vous possédez entièrement, car c’est là qu’un meilleur logiciel se traduit directement en avantage pour l’entreprise. Les sous-domaines de soutien méritent des conceptions saines mais plus simples, souvent un module en couches classique. Les sous-domaines génériques devraient généralement être achetés, utilisés sous forme de service ou construits comme de fins adaptateurs au-dessus de composants open source : construire votre propre fournisseur d’identité, c’est dépenser de l’effort là où vous ne pouvez pas gagner. Le classement évolue aussi avec le temps ; une capacité de soutien peut devenir cœur quand la stratégie de l’entreprise change.

Les contextes délimités

Un contexte délimité (bounded context) est une frontière explicite à l’intérieur de laquelle un modèle, et un langage omniprésent, s’appliquent de façon cohérente. À l’intérieur, « commande » a exactement un sens. À l’extérieur, le même mot peut signifier autre chose, et c’est acceptable, car chaque modèle est conçu pour un seul objectif. Evans a observé que vouloir unifier en un seul le modèle d’un grand système n’est ni faisable ni rentable ; la tentative produit d’énormes classes partagées qui servent mal tous les objectifs et que chaque équipe doit modifier.

Sous-domaines et contextes délimités sont des choses différentes, même s’ils sont souvent alignés. Un sous-domaine fait partie du problème : il existe dans l’entreprise, qu’il y ait un logiciel ou non. Un contexte délimité fait partie de la solution : une frontière que vous choisissez pour un modèle et, généralement, pour du code et des données qui appartiennent à une seule équipe. L’idéal est un contexte délimité par sous-domaine, mais les systèmes hérités ont souvent un seul contexte qui s’étend sur plusieurs sous-domaines, et un grand sous-domaine peut avoir besoin de plusieurs contextes.

Les cartes de contextes

Une carte de contextes (context map) montre les contextes délimités d’un système et les relations entre eux. Ces relations décrivent à la fois l’intégration technique et les rapports de force et de communication entre les équipes : c’est pourquoi la cartographie des contextes concerne autant les organisations que le code. C’est une application directe de la loi de Conway : la carte montre où les canaux de communication de l’organisation et les chemins d’intégration du système doivent coïncider.

Beaucoup de relations sont de type amont/aval (upstream/downstream) : les décisions du contexte amont affectent le contexte aval, mais pas l’inverse. L’équipe aval doit alors choisir comment s’en accommoder, et c’est ce choix que nomment la plupart des patrons.

Deux de ces patrons méritent une attention particulière. Une couche anticorruption (anticorruption layer, ACL) est un ensemble d’adaptateurs et de traducteurs qu’un contexte aval construit pour qu’un modèle étranger, souvent un système hérité ou un fournisseur externe, ne puisse pas s’infiltrer dans son propre modèle. C’est la même idée que l’adaptateur piloté de la section 5.6, appliquée entre contextes, et c’est le choix par défaut pour s’intégrer à tout ce que vous ne contrôlez pas. Un service hôte ouvert (open host service) associé à un langage publié (published language) est la façon dont l’amont sert bien de nombreux consommateurs : un seul protocole documenté et versionné au lieu d’une intégration sur mesure pour chacun. Un noyau partagé (shared kernel) doit rester petit ; un noyau partagé trop grand refait de deux contextes un seul, que deux équipes se disputent, et la référence d’Evans de 2015 ajoute la grosse boule de boue comme étiquette honnête pour une zone sans aucune frontière claire, qu’il faut contenir plutôt qu’étendre.

L’event storming : découvrir les contextes

Les frontières se découvrent avec les experts du domaine ; on ne les conçoit pas seul. L’event storming, créé par Alberto Brandolini et décrit pour la première fois sur son blog en 2013, est le format d’atelier le plus populaire pour cela. Les personnes qui connaissent le métier et celles qui construisent le logiciel se tiennent devant un long mur de papier et écrivent des événements de domaine (des choses qui se sont produites, au passé : Commande passée, Livreur affecté, Repas récupéré) sur des notes adhésives orange, qu’elles placent sur une ligne du temps.

Le groupe ajoute ensuite les commandes qui provoquent les événements, les personnes et les systèmes externes impliqués, les politiques qui réagissent aux événements (« chaque fois qu’une commande est passée, trouver un livreur ») et, surtout, les points chauds (hot spots), là où les gens ne sont pas d’accord ou où personne ne sait. Les groupes d’événements qui partagent un langage et un objectif suggèrent des contextes délimités ; les endroits où le même mot est employé différemment suggèrent des frontières ; les endroits où se produit un passage de relais suggèrent des points d’intégration. Une séance de vue d’ensemble (big picture) pour toute une entreprise dure un jour ou deux et ne demande presque aucune préparation, en dehors des bonnes personnes et de beaucoup de place au mur.

Les patrons tactiques en bref

À l’intérieur d’un contexte délimité, la DDD propose des blocs de construction pour le modèle. Une entité a une identité qui persiste pendant que ses attributs changent : une commande reste la même commande après un changement de statut. Un objet valeur (value object) n’a pas d’identité et n’est défini que par ses valeurs : deux objets Money(12.50, "GBP") sont interchangeables, et les objets valeur sont généralement immuables. Un événement de domaine enregistre quelque chose de significatif qui s’est produit dans le domaine.

Un agrégat est un groupe d’entités et d’objets valeur traités comme une seule unité pour les modifications, avec une entité comme racine. Le code extérieur ne peut détenir de références que vers la racine et ne doit modifier l’agrégat que par son intermédiaire, de sorte que la racine peut faire respecter les invariants de l’agrégat (des règles qui doivent toujours être vraies, comme « aucun article ne peut être ajouté après qu’une commande a été passée »). Une transaction ne devrait modifier qu’un seul agrégat ; les autres agrégats sont référencés par leur ID et mis à jour par des événements de domaine, ce qui fait des agrégats l’unité naturelle de cohérence et, plus tard, de distribution. Un repository charge et enregistre des agrégats entiers et se présente au domaine comme une collection ; son interface est un port piloté, en termes d’architecture hexagonale.

from dataclasses import dataclass, field
from decimal import Decimal

@dataclass(frozen=True)
class Money:                               # value object: equal if values equal
    amount: Decimal
    currency: str
    def __add__(self, other):
        if other.currency != self.currency:
            raise ValueError("currency mismatch")
        return Money(self.amount + other.amount, self.currency)
    def times(self, n: int):
        return Money(self.amount * n, self.currency)

@dataclass
class OrderLine:                           # entity inside the aggregate
    dish_id: str
    qty: int
    price: Money

@dataclass
class Order:                               # aggregate root
    id: str
    restaurant_id: str                     # other aggregates referenced by ID only
    lines: list[OrderLine] = field(default_factory=list)
    status: str = "draft"
    events: list = field(default_factory=list)

    def add(self, dish_id, qty, price):
        if self.status != "draft":
            raise ValueError("order already placed")    # invariant
        self.lines.append(OrderLine(dish_id, qty, price))

    def place(self, minimum: Money):
        total = Money(Decimal(0), minimum.currency)
        for line in self.lines:
            total = total + line.price.times(line.qty)
        if total.amount < minimum.amount:
            raise ValueError("below restaurant minimum")  # invariant
        self.status = "placed"
        self.events.append({"type": "OrderPlaced", "order_id": self.id, "total": str(total.amount)})

L’exemple garde l’agrégat petit, référence le restaurant par son ID au lieu de détenir un objet restaurant, et fait respecter ses règles dans des méthodes au lieu de les laisser aux appelants. Une erreur courante est l’inverse : des agrégats si grands que la modification de chaque utilisateur verrouille les mêmes lignes, ou des objets du domaine qui ne sont que des sacs de getters et de setters, tandis que les règles vivent dans des classes de service (Martin Fowler appelle cela le modèle de domaine anémique).

Les contextes délimités comme frontières de modules et de services

Les contextes délimités sont le meilleur guide disponible pour savoir où tracer les frontières des modules dans un monolithe et celles des services dans un système distribué. Un contexte a son propre modèle, son propre langage, ses propres données et, idéalement, une seule équipe propriétaire : ce sont exactement les propriétés qui rendent un module cohésif et faiblement couplé. Dans un monolithe modulaire, chaque contexte devient un module avec son propre schéma ; à l’intérieur, la structure hexagonale de la section 5.6 garde le modèle indépendant de l’infrastructure.

Si un contexte doit plus tard être déployé séparément, sa frontière a déjà la bonne forme pour un service, et ses relations sur la carte de contextes vous indiquent à quoi doit ressembler l’intégration. C’est pourquoi de nombreux praticiens recommandent de trouver d’abord les contextes et de décider du déploiement ensuite. L’inverse est vrai aussi : des services qui traversent les contextes délimités (un « service des commandes » dans lequel écrit chaque contexte) produisent le monolithe distribué fortement couplé étudié à la section 6.3. Notez aussi qu’un contexte délimité n’est pas automatiquement un microservice ; un contexte peut être déployé sous forme de plusieurs services, et plusieurs petits contextes peuvent partager un même déploiement.