La conception pilotée par le domaine (DDD) consiste à concevoir un logiciel en fonction du domaine métier, et non des bases de données, des frameworks ou des technologies. Elle repose sur un modèle de domaine précis et partagé, élaboré conjointement par les experts du domaine et les développeurs. Ce modèle structure le code, la communication au sein de l'équipe et les interfaces. L'objectif : rendre la logique métier complexe gérable, réduire les risques et déployer les modifications plus rapidement et en toute sécurité.
Ce qu'est réellement DDD
Le DDD est une méthode de travail et une approche architecturale. On conçoit le logiciel en fonction des besoins du domaine. Chaque règle importante, chaque terme – de « limite de crédit client » à « approbation de commande » – est traduit clairement dans le code par un terme et une opération. Au lieu d'une « table des commandes » à 50 colonnes, on utilise un modèle vivant : un Commande avec des positions, un tentative de paiementun Bon de livraisonTout est clairement délimité, avec des frontières nettes (contextes délimités) et sans magie implicite.
Idées et concepts clés
Langage omniprésent : Un langage technique commun et précis, utilisé de manière identique dans les conversations, les tickets et le code. N'utilisez pas « CustomerLimit » dans le code lorsque le terme métier est « limite de crédit ».
Domaine et sous-domaines : Le secteur d'activité (par exemple, le commerce) est divisé en sous-secteurs : cœur de métier (Avantage compétitifUn avantage concurrentiel est la raison concrète pour laquelle les clients vous choisissent plutôt qu'un concurrent, de manière constante et mesurable. Il peut s'agir d'un avantage de prix, d'un... Cliquez pour en savoir plus), sous-domaines de support et génériques. DDD permet d'isoler le cœur du système afin que la qualité et la vitesse y soient prioritaires.
Contexte délimité : Un champ sémantique clairement défini. « Client » dans DistributionLe profil du client idéal est une description précise de l'entreprise qui correspond le mieux à votre offre, à vos méthodes de travail et à vos objectifs commerciaux. Cliquez pour en savoir plus Le terme « client » a une signification différente de celle qu'il a en comptabilité. Chaque contexte possède son propre modèle, ses propres règles et souvent son propre système de persistance des données. La communication entre les contextes s'effectue par des traductions explicites.
Carte contextuelle : La carte des contextes et de leurs relations. Elle indique où des traductions sont nécessaires, qui dépend de qui (par exemple, en amont/en aval) et où des mécanismes de protection sont mis en place.
Couche anti-corruption (ACL) : Une couche protectrice qui préserve un modèle propre d'un modèle « étranger ». En termes pratiques, il s'agit d'une traduction : le « langage hérité » s'infiltre à l'extérieur, tandis que votre langage universel reste propre à l'intérieur.
Motifs tactiques : Éléments constitutifs du code : Entité (possède une identité), Objet valeur (valeur équivalente, inchangée ; par exemple, montant d'argent en monnaie fiduciaire), Total (Limites de cohérence et invariants), Service de domaine (Logique technique sans foyer naturel), Dépôt (Stockage de granulats), Événements de domaine (« Commande exécutée » – un événement important s’est produit). Services d'application Elles orchestrent les cas d'utilisation, mais ne contiennent pas de logique centrale.
Limites de transaction et de cohérence : Un agrégat garantit l'invariance au niveau atomique. Entre agrégats, on accepte souvent une « cohérence éventuelle » ; en contrepartie, on gagne en évolutivité et en clarté des limites.
Un exemple pratique
Imaginez une boutique en ligne. Dans le sous-domaine « Commande », un objet agrégé « Commande » gère les articles, le montant total et l’approbation. Une commande ne peut être approuvée que si tous les articles sont disponibles et que le montant total est couvert. L’approbation déclenche un événement de domaine « CommandeApprouvée ». Un autre contexte, « Paiement », reçoit cet événement et initie le débit. Un troisième contexte, « Logistique », réagit et crée un ordre d’expédition. Chaque contexte possède son propre modèle : pas d’objet unique ni de table omnipotente.
Dans le domaine du crédit, la situation est similaire : la « ligne de crédit » globale garantit qu’un nouveau prêt ne dépassera jamais la limite approuvée. Cette décision est intégrée au modèle, et non soumise à une validation via l’interface utilisateur. Ceci assure une application cohérente de la règle.
Approche pratique – étape par étape
Commencez par dialoguer. Réunissez développeurs et experts métiers pour recenser les termes, règles et exceptions. Soyez attentif aux petits mots clés (« en fait », « sauf si »). C'est là que se cachent les subtilités. Visualisez les processus et les événements. Inutile d'avoir une représentation parfaite : une ébauche suffit.
Délimitez les contextes. Analysez : où le sens des termes change-t-il ? Où les règles deviennent-elles contradictoires ? Deux modèles simples et clairs valent mieux qu'un seul, vaste et imprécis. Élaborez la carte du contexte en indiquant les rôles (fournisseurs, consommateurs) et définissez les interfaces. Là où un système hérité prédomine, ajoutez une couche de protection contre la corruption.
Définissez des agrégats avec des invariants clairs. Formulez-les sous forme de phrases : « Une commande ne peut être validée que si… ». Implémentez ensuite des méthodes qui reflètent ces phrases. ValeurSi vous avez déjà assisté à un lever de soleil, vous savez comment le monde émerge lentement de l'obscurité et se laisse baigner d'une lumière dorée. Ceci... Cliquez pour en savoir plus Les objets devraient être véritablement immuables et riches en logique (par exemple, ajouter un prix, vérifier la devise), au lieu de disperser des types primitifs partout.
Utilisez les événements de domaine. Nommez-les en utilisant la terminologie du domaine. Servez-vous-en pour découpler les contextes. En interne, ils vous aident à gérer plus efficacement les effets de bord. Acceptez que tout ne doive pas nécessairement se dérouler de manière synchrone, pourvu que les exigences métier soient respectées.
Itérez. Le DDD n'est pas une transformation radicale. Commencez par la zone la plus risquée, apprenez, affinez le langage, puis définissez les limites. Les bons modèles émergent des échanges et des retours d'expérience en situation de production réelle.
Erreurs courantes – et comment les éviter
Unités surdimensionnées : si une unité se bloque constamment ou doit être chargée partout, elle est trop volumineuse. Réduisez sa taille, vérifiez les invariants et coordonnez le reste via des événements.
Un langage omniprésent uniquement dans les diapositives : si le code utilise des termes différents de ceux employés lors de la réunion quotidienne, le modèle devient inopérant. Utilisez une terminologie cohérente.
Conception pilotée par le domaine (DDD) sans véritables experts métier : sans expertise du sujet, vous modélisez la technologie, pas le métier. Impliquez régulièrement les équipes métier dans la discussion, en utilisant des exemples, des cas particuliers et des données réelles.
Les contextes envisagés comme une structure de dossiers plutôt que comme des espaces de signification : un module n’est pas un contexte délimité. L’essentiel est que les termes qui s’y trouvent soient cohérents et traduits en dehors de celui-ci.
« Tout est synchrone, tout est transactionnel » : une cohérence stricte entre les contextes semble rassurante, mais rend les systèmes lents et fragiles. Mieux vaut privilégier des invariants stricts au sein d’un agrégat, des garanties de domaine claires et un couplage asynchrone.
Quand le DDD est pertinent – et quand il ne l'est pas
Le DDD est pertinent si votre logique métier est complexe, dynamique ou critique. Lorsque les règles changent fréquemment, que de nouveaux produits sont développés ou que plusieurs équipes travaillent en parallèle, des contextes clairs et un langage fort sont extrêmement utiles. Le DDD est moins avantageux si vous développez uniquement une application CRUD simple sans logique complexe. Dans ce cas, les efforts à fournir sont supérieurs aux avantages.
Foire aux Questions
Que signifie la conception pilotée par le domaine (DDD) en une phrase ?
Vous modélisez le logiciel en fonction du domaine métier : langage commun, limites claires (contextes délimités), éléments constitutifs ciblés (agrégats, entités, objets de valeur) – afin que la logique métier complexe reste compréhensible, modifiable et fiable.
Quels sont les avantages spécifiques pour les entreprises et les startups ?
Le DDD réduit les erreurs et les efforts de coordination car tous les acteurs partagent la même vision. Les équipes travaillent plus vite car l'application de chaque règle est clairement définie. Résultat : un délai de mise sur le marché plus court, moins d'erreurs en production et une meilleure gestion des changements, notamment lorsque la logique métier constitue un avantage concurrentiel.
Qu’est-ce qu’un contexte délimité – et comment le reconnaître ?
Un contexte délimité est un espace où les termes et les règles sont cohérents. On le reconnaît lorsque le sens d'un mot change (par exemple, « client » dans le service commercial et dans le service comptable) ou lorsqu'une équipe peut travailler de manière autonome. Concrètement : il faut analyser les changements. Si un changement affecte constamment de nombreux éléments, la limite est mal définie ; si les changements restent localisés, elle est bien définie.
Entité, objet valeur, agrégat – quelles différences ?
Les entités conservent leur identité dans le temps (par exemple, le client n° 4711). Les objets de valeur sont définis par des valeurs et sont immuables (par exemple, un montant de 10,00 €). Un agrégat regroupe les entités/objets de valeur et définit les invariants et les limites des transactions. Seule la racine de l’agrégat peut être modifiée en externe, ce qui garantit la centralisation des règles.
Comment puis-je me lancer dans la conception pilotée par le domaine (DDD) sans reconstruire l'intégralité du système ?
Choisissez un sous-domaine à risque ou en constante évolution. Définissez le langage et les règles, établissez un contexte délimité, mettez en place une couche anti-corruption devant les systèmes existants et implémentez un agrégat initial avec des invariants clairs. Recueillez des retours et développez progressivement. Vous minimiserez ainsi les risques et apprendrez rapidement.
Ai-je besoin de microservices pour le DDD ?
Non. DDD est indépendant de MicroservicesÀ première vue, le terme « microservices » semble réservé aux développeurs. Mais analysons-le : imaginez que vous ayez… Cliquez pour en savoir plusVous pouvez commencer par une architecture monolithique avec des contextes clairement séparés. Par la suite, ces contextes peuvent être extraits sous forme de services, si cela s'avère pertinent. L'architecture découle du modèle, et non l'inverse.
Comment gérer les systèmes hérités qui « polluent » mon modèle ?
Insérez une couche anti-corruption entre votre modèle propre et le système existant. Cette couche traduit les termes et les formats de données. Ainsi, votre langage commun reste intact pendant que vous modernisez progressivement, sans rupture brutale.
Comment garantir la cohérence entre les différents contextes ?
Les invariants stricts restent transactionnels au sein d'un agrégat. Entre les contextes, vous utilisez des événements de domaine et des réponses asynchrones. Prévoyez des garanties métier (par exemple, « commande de livraison uniquement après validation de la commande »), mettez en œuvre des mécanismes de compensation pour les erreurs et surveillez les flux. La cohérence éventuelle est acceptable si les règles métier le permettent.
Quels changements organisationnels DDD prend-il en charge ?
Le DDD favorise l'autonomie des équipes, organisées autour de contextes délimités. Les équipes métiers et techniques collaborent plus étroitement, les réunions sont plus courtes grâce à une terminologie clairement définie. Les transferts de responsabilités sont réduits car la répartition des responsabilités selon les contextes accélère les mises en production.
Le DDD n'est-il pas trop « lourd » pour les petites équipes ?
La boîte à outils est vaste, mais vous n'êtes pas obligé de tout utiliser. Deux choses font une différence immédiate : l'utilisation systématique d'un langage commun dans votre code et la création de contextes clairs. Ces deux éléments sont peu coûteux, mais apportent beaucoup de structure et de rapidité, même dans les petites équipes.
Comment puis-je mesurer si la méthode DDD fonctionne pour nous ?
Soyez attentif aux indicateurs : les changements sont-ils plus localisés ? Le nombre de scénarios d’erreurs techniques diminue-t-il ? Le délai entre l’idée et sa mise en production est-il plus court ? Les nouveaux collaborateurs comprennent-ils plus rapidement le domaine ? Si oui, votre modèle est viable.
Quels sont les anti-modèles typiques à éviter ?
Modèles de domaine « anémiques » (logique dans les services, données dans les objets), agrégats surdimensionnés, couplage caché via des tables partagées, terminologie incohérente dans le code et les échanges, et réflexe de « synchronisation généralisée ». Solutions : exprimer les invariants dans les agrégats, séparer clairement les contextes, utiliser les événements et maintenir un langage rigoureux.
Comment gérer les modèles de reporting et de lecture ?
Séparez les modèles d'écriture et de lecture lorsque cela s'avère pertinent : le modèle de domaine optimise les règles et la cohérence, tandis que le modèle de lecture optimise les requêtes et la présentation. Privilégiez les projections alimentées par les événements du domaine. Vous obtiendrez ainsi une logique métier allégée et des rapports rapides.
Conclusion et recommandation
Le DDD n'est pas un dogme, mais une invitation à concevoir des logiciels qui reflètent fidèlement le fonctionnement de votre entreprise. Commencez par des étapes simples : clarifiez le langage, définissez les contextes, implémentez un premier agrégat avec un invariant strict. Observez, apprenez et ajustez. Si vous avez besoin d'un accompagnement ou d'un regard extérieur sur votre cartographie des contextes, l'équipe Berger+Team peut vous apporter un soutien pragmatique, axé sur une terminologie claire, des interfaces épurées et des solutions pratiques.
