La GenAI est-elle compatible avec Domain-Driven Design Tactique

La GenAI est-elle compatible avec Domain-Driven Design Tactique ?

La vague de l’IA submerge tout sur son passage

Introduction

Depuis quelque temps, les réseaux sociaux sont submergés par une vague autour de l’IA générative. Tout le monde en parle. De nouveaux ténors du sujet émergent et s’expriment avec une grande assurance, arborant des titres tels que experts IA ou assimilés. Le discours dominant est souvent le même : les développeurs qui persistent à coder à la main seraient déjà en retard, voire inutiles, puisque l’IA serait capable de produire un code « honnête » en un temps record.

Le message sous-jacent est brutal : soit vous acceptez l’IA sans réserve, soit vous êtes condamnés à disparaître. Je m’excuse par avance pour ce ton volontairement provocateur, mais il reflète assez fidèlement l’ambiance actuelle. Justement, cette situation appelle une prise de recul. Avant d’adhérer à ces discours simplificateurs, il est nécessaire de ralentir, d’analyser et de chercher à y voir plus clair.

Les praticiens du Domain-Driven Design savent que tout le code ne se vaut pas. En particulier, le code du sous-domaine cœur a une responsabilité spécifique : il doit exprimer le métier avec une telle clarté qu’un non-informaticien, ou à tout le moins un expert métier, puisse en comprendre l’intention sans effort excessif. Ce code n’est pas qu’un assemblage d’instructions exécutables ; il est un langage, une narration précise du domaine.

Dans ce contexte, « produire du code rapidement » n’est pas un objectif en soi. Ce qui compte, c’est l’expressivité, la précision du vocabulaire, le respect des règles métier et la capacité du modèle à évoluer sans se dégrader. Or, ces qualités ne se décrètent pas et ne s’obtiennent pas mécaniquement par génération automatique. Elles sont le fruit d’un travail de modélisation conscient, d’échanges avec le métier et d’arbitrages que seule une compréhension profonde du domaine permet de réaliser.

La question n’est donc pas de savoir s’il faut accepter ou refuser l’IA, mais de comprendre où, comment et jusqu’à quel point elle peut être utilisée sans compromettre la qualité du modèle. Dans le sous-domaine cœur, où le code est avant tout un outil de compréhension partagée du métier, la prudence n’est pas un conservatisme : c’est une exigence de design.

Dans une vidéo d’introduction à son nouveau cours Strategic Design with Eric Evans, proposé par la société Avanscoperta, Eric Evans est interviewé par Marco Heimeshoff. Au cours de cet échange, une question émerge concernant la compatibilité de l’IA générative avec le Model-Driven Design. J’ai donc choisi de reprendre les propos d’Eric afin de leur apporter du recul et de la perspective.

Strategic Design with Eric Evans - YouTube

Model-Driven Design Quesaco

Le Model-Driven Design représente le versant « modélisation » du Domain-Driven Design du point de vue du code. Il ne s’agit pas simplement d’écrire des classes ou d’organiser des couches techniques, mais de construire un modèle logiciel capable d’exprimer fidèlement le domaine métier — en priorité dans le sous-domaine cœur, et parfois dans certains sous-domaines support lorsque cela s’avère pertinent.

Pour atteindre cet objectif, le Model-Driven Design repose sur trois piliers complémentaires : les Building Blocks, le Supple Design et le Deep Modeling.

Les Building Blocks constituent une véritable boîte à outils conceptuelle. Entités, objets valeur, agrégats, services, repositories ou événements de domaine fournissent un vocabulaire structurant pour traduire les concepts métier dans le code. Il ne s’agit pas de simples patterns techniques, mais d’éléments de langage dont la finalité est de rendre le modèle explicite, lisible et partageable entre développeurs et experts métier.

Le Supple Design regroupe un ensemble de principes et de patterns visant à maintenir un modèle vivant dans le temps. Son ambition est de produire un code expressif, maintenable et capable d’évoluer au rythme de l’approfondissement du métier. Il encourage la clarté, l’élimination des ambiguïtés et l’alignement constant entre le langage du code et le langage du domaine.

Le Deep Modeling, enfin, décrit une démarche de modélisation itérative et collaborative. Le modèle n’est jamais figé : il s’affine progressivement grâce aux échanges avec les experts métier, aux découvertes fonctionnelles et aux retours d’expérience. Cette profondeur de modélisation est au cœur de la valeur du Domain-Driven Design, car elle permet de capturer les invariants métier de manière simple, fiable et durable.

La philosophie du Model-Driven Design est également marquée par une forme de frugalité. Chaque élément de code doit justifier sa présence. L’objectif est d’éliminer tout ce qui est superflu afin de préserver la clarté et la pertinence du modèle. Cette exigence conduit à une approche où la qualité du design repose autant sur ce que l’on choisit d’exprimer que sur ce que l’on décide de ne pas conserver.

Classification des Bounded Contexts par affinité de valeur

Dans une démarche de Domain-Driven Design, les sous-domaines — et, par extension, les Bounded Contexts qui les incarnent — sont classés en trois catégories de sous-domaines: Coeur, Support et Générique.

Cette distinction ne relève pas uniquement d’une organisation technique ou structurelle. Elle vise avant tout à orienter l’investissement intellectuel et stratégique vers les zones qui créent le plus de valeur pour l’entreprise.

Le sous-domaine Coeur est celui qui porte l’avantage concurrentiel. Il concentre les règles métier les plus fines — les invariants au sens du DDD —, les connaissances les plus différenciantes et les décisions structurantes qui donnent au produit ou au service sa singularité.
C’est dans ce périmètre que la compréhension du métier doit être la plus approfondie, la plus exigeante et la plus largement partagée entre experts et développeurs.

Le code du sous-domaine Core revêt donc une responsabilité particulière. Il doit refléter le modèle métier avec précision, tout en demeurant sobre, explicite et intelligible. Chaque concept, chaque règle et chaque invariant doivent être exprimés clairement, sans complexité accidentelle ni artifice technique superflu.
Ce code n’est pas uniquement destiné à être exécuté par une machine : il constitue avant tout un support de compréhension collective, un vecteur de langage ubiquitaire et un outil d’évolution du modèle dans le temps.

La question de la compatibilité de la GenAI avec le sous-domaine Core se pose alors naturellement dans une démarche de Model-Driven Design. Si l’intelligence artificielle générative peut produire du code rapidement et avec une efficacité apparente, elle ne possède pas une compréhension profonde du métier. Or, dans le Core, le code n’est pas interchangeable : il incarne un savoir construit au fil d’échanges, d’arbitrages subtils et d’une compréhension partagée entre experts métier et développeurs.

Déléguer cette responsabilité à une génération automatique comporte un risque réel : celui de diluer le sens, d’affaiblir la cohérence du modèle et de rompre l’alignement avec le langage ubiquitaire.

Passage à la loupe des différents sous domaine vis à vis la GenAI

Afin de clarifier explicitement la position de la GenAI, examinons sa pertinence pour chacun des types de sous-domaines.

Le sous-domaine générique

Si vous possédez un ou plusieurs sous-domaines génériques, l’usage de la GenAI doit d’abord être mis en perspective. Par définition, un sous-domaine générique est substituable par un produit du marché. La première question à se poser n’est donc pas technologique, mais stratégique : faut-il réellement continuer à le développer en interne ?

Cependant, si l’organisation choisit de conserver un ou plusieurs sous-domaines génériques dans sa base de code, alors l’usage de la GenAI devient pertinent. Vous pouvez tirer parti des capacités actuelles des outils pour moderniser ces parties du système, améliorer leur maintenabilité ou accélérer leur évolution, à condition que cette transformation soit réellement porteuse de valeur. Dans ce contexte, l’IA peut constituer un levier d’efficacité intéressant, sans mettre en péril la singularité métier de l’organisation.

Le sous-domaine support

Les sous-domaines support sont essentiels au bon fonctionnement du sous-domaine cœur, car ils contribuent activement à son efficacité opérationnelle. Toutefois, la complexité métier y est généralement moindre. Les règles sont plus explicites, plus standardisées et moins stratégiques.

Ce contexte en fait un terrain particulièrement favorable à l’usage de la GenAI. Vous pouvez y obtenir un code adapté, souvent plus propre et plus homogène que celui produit auparavant, notamment si vous intervenez sur une base existante. Et si vous démarrez un nouveau sous-domaine support, l’IA peut vous aider à poser rapidement une structure saine, tout en vous permettant de concentrer votre énergie sur le cœur métier.

Le sous-domaine cœur

L’usage de la GenAI dans le sous-domaine cœur ne doit pas être exclu par principe. Si vous êtes profondément engagé dans la compréhension du métier et que vous maîtrisez suffisamment les outils pour orienter précisément la génération, l’expérimentation peut être envisagée. Toutefois, cette utilisation exige un niveau d’exigence particulièrement élevé.

Il ne suffit pas de vérifier que le code compile ou qu’il fonctionne correctement. L’enjeu central réside dans son expressivité métier. Les primitives techniques ont-elles été remplacées par des objets porteurs de sens ? Les concepts clés du domaine sont-ils incarnés par de véritables Value Objects ou agrégats cohérents ? Le code reflète-t-il fidèlement le modèle du domaine et le langage ubiquitaire partagé avec les experts métier ?

Si la génération produite manque de précision ou affaiblit le modèle, il est préférable de reprendre la main. Retravailler le code manuellement, clarifier les concepts et réaffirmer les invariants métier permet de rétablir une base saine. La GenAI s’appuie sur le contexte existant pour générer la suite : plus le code est explicite, aligné sur le métier et structuré selon les principes du design, plus les générations futures seront pertinentes.

L’axe de frugalité vise à orienter la conception vers l’élimination des éléments inutiles à la résolution du problème. Il s’agit de se concentrer strictement sur ce qui apporte de la valeur au regard du besoin métier, en évitant les raffinements techniques ou les ajouts superflus qui complexifient inutilement la solution.

Dans cette perspective, la frugalité contribue également à un usage mesuré de la GenIA. Si ces outils peuvent accélérer la production de code, ils génèrent parfois des solutions plus riches, voire plus lourdes que nécessaire. Le code produit n’est pas toujours frugal au regard des exigences précises du sous-domaine cœur, qui requiert souvent une modélisation fine, intentionnelle et alignée sur les invariants métiers.

Adopter une posture de frugalité consiste donc à exercer un regard critique sur le code généré, à en simplifier les structures lorsque cela est pertinent, et à s’assurer qu’il sert réellement la compréhension et la maîtrise du modèle métier.

Dans cette perspective, une approche prudente s’impose. La GenAI trouve plus naturellement sa place dans les sous-domaines génériques ou supports, où l’objectif principal est l’efficacité. Dans le sous-domaine cœur, en revanche, elle ne peut être qu’un outil placé sous contrôle strict.

Elle peut devenir un levier utile dans une démarche tactique de Domain-Driven Design, à condition de respecter une frontière claire : automatiser ce qui relève du générique ou du support, et préserver le sous-domaine cœur comme un espace de modélisation profondément humain, intentionnel et ancré dans une compréhension fine du métier. Si vous choisissez malgré tout d’y recourir, cela implique un regard particulièrement attentif sur le code généré et une responsabilité pleinement assumée sur chaque décision structurante.

Plateforme de réservation de place dans les théâtres

Afin d’illustrer un cas d’usage illustré par exemple concret, je vous propose un domaine où nous évoluons au sein d’une société qui gère une grande partie des théâtres parisiens. Dans ce contexte, l’objectif est de concevoir et développer une nouvelle plateforme de réservation. Cette plateforme devra mettre en avant un concept innovant d’allocation des sièges pour les spectateurs, fondé sur des approches issues de nos travaux de recherche. L’ambition est d’améliorer l’expérience utilisateur tout en optimisant la gestion des salles et des représentations.

À l’issue d’un atelier d’EventStorming Big Picture particulièrement concluant, nous avons pu clarifier la vision globale du domaine, identifier les grands flux métier et mettre en évidence les interactions clés entre les différents sous-domaines.

À ce stade, bien que la structuration du paysage applicatif soit posée, nous n’avons pas encore défini l’affinité de valeur. Cette étape reste à mener afin de préciser la manière dont chaque contexte contribue à la proposition de valeur globale, et d’orienter plus finement les décisions stratégiques et organisationnelles.

Passe en revue chaque sous-domaine

Pour chaque sous-domaine, un argumentaire précis est associé afin d’évaluer et de qualifier son affinité de valeur au regard de la stratégie métier et du niveau d’avantage concurrentiel recherché :

• Marketing & Communication

Le sous-domaine chargé de la promotion des événements combine campagnes marketing, SEO et diffusion multicanale pour accroître la visibilité des spectacles et stimuler la fréquentation. L’analytics et le marketing automation permettent d’analyser les comportements et d’automatiser des communications personnalisées afin d’optimiser l’engagement du public.

• Réservation

Le sous-domaine Réservation couvre le parcours complet de sélection d’un spectacle, du choix de l’événement et des sièges jusqu’à la validation du panier et la confirmation de la réservation. Il intègre une politique d’allocation avancée proposant des sièges recommandés selon des catégories de prix et des contraintes de groupe, rendant le modèle métier riche et structuré.

• Billetterie

Le sous-domaine Billetterie intervient après la réservation pour gérer le paiement, l’émission des billets et le contrôle d’accès associé. Il couvre aussi les annulations et remboursements, en assurant la sécurité des transactions et l’intégration avec des prestataires de paiement externes.

• Paiement

L’intégration de prestataires de paiement assure des transactions en ligne fluides et sécurisées, tout en garantissant la cohérence du parcours utilisateur. Elle inclut la gestion des remboursements et la conformité PCI-DSS, afin d’assurer la traçabilité financière, la des données et la confiance des spectateurs.

• Programmation et Organisation de la Saison

Ce domaine regroupe la gestion complète de la programmation théâtrale : spectacles, artistes, productions, contrats, plannings et affectation des salles. Il vise à construire une saison cohérente en coordonnant les choix artistiques, les contraintes opérationnelles et l’optimisation de l’occupation des salles.

• Gestion du public

Le suivi des visiteurs permet d’analyser les comportements du public afin d’adapter la programmation, la communication et la tarification. Adhésions, abonnements et dispositifs de fidélité renforcent l’engagement des spectateurs et contribuent à stabiliser la fréquentation et les revenus du théâtre.

Synthèse des sous-domaines par affinité de valeur

Afin d’analyser l’usage potentiel de l’IA pour chaque sous-domaine métier, en regard de son affinité de valeur et de sa contribution à l’avantage concurrentiel, je vous propose le tableau récapitulatif ci-dessous.

À l’issue de cet exercice mené sur la base d’un domaine métier concret, il apparaît que la GenAI peut être largement mobilisée sur la majorité des sous-domaines sans soulever de questionnement majeur : 5 sous-domaines compatibles sur un total de 6. Les sous-domaines génériques et de support, reposant sur des pratiques largement connues et standardisées, se prêtent particulièrement bien à l’usage de ces technologies, que ce soit pour accélérer la production, automatiser certaines tâches ou améliorer la qualité globale des livrables.

La principale zone d’attention concerne toutefois le sous-domaine cœur. Par nature, celui-ci porte la différenciation métier et constitue le principal levier d’avantage concurrentiel. Son évolution est souvent soumise à des incertitudes fonctionnelles, à des ajustements progressifs et parfois à des pivots stratégiques significatifs.

Dans ce contexte, l’usage de la GenAI doit s’accompagner d’une vigilance accrue quant à la qualité de la modélisation. Une conception insuffisamment maîtrisée pourrait figer prématurément certaines décisions et conduire à une dégradation progressive du modèle, transformant le code en legacy difficile à faire évoluer. Le soin apporté au design du domaine, à l’expression du langage ubiquitaire et à la maîtrise des invariants métier reste donc essentiel afin de préserver la capacité d’adaptation du système dans le temps.

La Gen AI compatible avec Domain-Driven Design

Bien que la tendance actuelle encourage l’intégration de la GenAI à tous les niveaux des systèmes d’information, son utilisation dans la dimension tactique du Domain-Driven Design nécessite une approche mesurée.

Lors de la présentation de son nouveau cours, Strategic Design for Today’s Software Teams, Eric Evans a partagé avec la communauté DDD sa position concernant l’usage de la GenAI dans une démarche de Model-Driven Design. Autrement dit, la GenAI n’est pas incompatible avec le DDD tactique, mais son utilisation doit être adaptée à la nature du sous-domaine concerné ainsi qu’aux enjeux qu’il porte.

Dans les sous-domaines support, et parfois génériques, où le recours à des solutions sur étagère demeure pertinent, l’objectif principal relève davantage de l’efficacité opérationnelle que de la différenciation stratégique. Dans ce contexte, l’IA constitue un levier particulièrement efficace : elle accélère la production logicielle, favorise l’homogénéité du code et réduit la charge cognitive des équipes. Ces bénéfices permettent de réallouer l’énergie vers des activités à plus forte valeur métier.

À l’inverse, dans le sous-domaine cœur, le code assume une responsabilité particulière. Il incarne une compréhension fine du métier et matérialise le langage ubiquitaire, les concepts clés ainsi que les invariants du modèle. La GenAI ne disposant pas intrinsèquement de cette compréhension profonde du domaine, son utilisation exige une vigilance accrue : chaque production doit être évaluée au regard de sa justesse métier, de son alignement avec le modèle et de sa capacité à exprimer clairement l’intention métier.