Tout le monde est d’accord sur le principe : modéliser le domaine avant de dessiner l’architecture. En pratique, ça dure rarement plus de deux sprints avant que l’équipe revienne à ce qu’elle connaît.
Ce n’est pas un manque de discipline. C’est une confusion de niveaux.
Le domain model et la target architecture ne sont pas des étapes successives du même exercice. Ce sont deux exercices fondamentalement différents — avec des outils différents, des participants différents, et des objectifs différents. Les confondre, c’est garantir que votre nouvelle architecture reproduit les contraintes de l’ancienne.
Problem space et solution space — de la mécanique, pas de la philosophie
La distinction n’est pas conceptuelle. Elle est opérationnelle.
Le domain model appartient au problem space : il décrit ce que votre organisation fait, indépendamment de tout système. Quels sont les processus métier réels ? Quelles sont les règles qui gouvernent ces processus ? Qui en est responsable ? Ce niveau d’analyse ne connaît pas les tables de base de données, les microservices, ni les contraintes de migration. Il ne connaît que la réalité opérationnelle.
La target architecture appartient au solution space : elle décrit comment des systèmes techniques vont servir cette réalité. Quels services, quelles APIs, quels patterns (CQRS, event sourcing, bounded contexts) pour implémenter les règles métier identifiées au niveau précédent ?
| Domain model | Target architecture | |
|---|---|---|
| Question | Que fait vraiment l’organisation ? | Comment la technologie va-t-elle le servir ? |
| Niveau | Problem space | Solution space |
| Participants | Domain experts, product owners | Architectes, tech leads |
| Outils | Event storming, context mapping | Diagrammes C4, ADRs, bounded contexts |
| Contrainte | Aucune — délibérément | Budget, stack existante, équipe |
| Output | Ubiquitous language, bounded contexts | Service map, migration plan |
La séquence est non-négociable. Le domain model doit précéder la target architecture — pas parce que c’est élégant, mais parce que sans lui, vos bounded contexts reflètent votre organigramme IT, pas votre réalité métier.
Ce que les équipes font à la place — et pourquoi c’est rationnel
En pratique, voici ce qui se passe dans la plupart des projets de modernisation.
L’équipe commence par un atelier de domain modeling. Trois jours d’event storming, des post-its partout, de l’énergie. Puis le premier sprint de delivery démarre. Le backlog s’accumule. Les stakeholders demandent des démos. Le CTO est pris entre la pression du delivery et la dette du domain modeling inachevé.
Au troisième sprint, le domain model devient silencieusement une target architecture déguisée. Les bounded contexts se calquent sur les modules de l’ERP existant. L’ubiquitous language se contamine du vocabulaire du système legacy. On commence à entendre “oui mais dans notre système actuel, c’est structuré comme ça” — et personne ne remet en question ce “comme ça”.
Ce comportement est rationnel. Le CTO fait face à des contraintes réelles : une équipe qui doit délivrer, des managers qui veulent voir avancer, un budget qui ne couvre pas six mois de modeling théorique. La pression de se raccrocher à ce qui existe est structurellement inévitable.
Le problème n’est pas la volonté. C’est le dispositif.
Les symptômes du court-circuit
Quand le domain modeling a été court-circuité, les signes apparaissent plusieurs mois plus tard — souvent après le go-live.
Les bounded contexts épousent l’organigramme. Si vos services correspondent exactement à vos équipes IT actuelles, c’est suspect. Les bounded contexts doivent refléter la réalité métier, pas les frontières organisationnelles existantes.
L’ubiquitous language est pollué par le legacy. Les développeurs et les domain experts parlent du même concept avec des termes différents. Ou pire : ils utilisent le même terme pour des concepts différents. C’est le signe que le domain modeling s’est arrêté en surface.
Les règles métier sont éparpillées dans le code. Sans domain model formalisé, les règles métier finissent dans les couches techniques — du SQL, des validations dans les controllers, des conditions dans les event handlers. Impossible à maintenir, impossible à expliquer aux domain experts.
La migration reproduit l’existant. Module par module, table par table, le nouveau système copie l’ancien avec une nouvelle stack. Nouvelle technologie, mêmes contraintes.
J’ai vu ce pattern dans des projets à 1,5M€ livrés dans les temps, dont les utilisateurs étaient frustrés dès le go-live. Ce n’était pas un échec de delivery. C’était un échec de design.
Comment le faire survivre au contact du delivery
Le domain modeling meurt dans la pression du delivery parce qu’il est positionné comme une phase — avec un début, une fin, et une passation. Ce n’est pas le bon modèle.
Séparer les deux horizons temporellement. Le domain modeling doit précéder le delivery d’au moins quatre à six semaines. Si l’atelier d’event storming démarre en même temps que le premier sprint, il n’a aucune chance. La pression du delivery mange toujours l’abstraction.
Protéger le domain modeling de la contingence. Quelqu’un doit être responsable de maintenir l’intégrité du domain model tout au long du projet — indépendamment de la pression des sprints. Ce rôle n’est pas celui du tech lead plongé dans le delivery. C’est typiquement un architecte ou un consultant externe qui n’est pas pris dans l’exécution quotidienne.
Valider avec les domain experts, pas avec les développeurs. L’ubiquitous language se construit avec ceux qui vivent les processus métier, pas avec ceux qui vont les coder. Si votre event storming n’a que des développeurs dans la salle, vous modélisez votre system model, pas votre domain model.
Tester contre des cas limites réels. Avant de passer à la target architecture, confronter le domain model aux situations les plus complexes — les exceptions, les cas particuliers, les règles qui semblent contradictoires. C’est là que les lacunes apparaissent, pas dans les flux nominaux.
Documenter le “pourquoi” des bounded contexts. Chaque bounded context doit pouvoir s’expliquer en une phrase métier, sans jargon DDD. Si vous ne pouvez pas l’expliquer à un directeur métier, c’est que vous avez modélisé un artefact technique, pas un concept métier.
Donc, concrètement
Si vous êtes CTO d’un projet de modernisation en cours, une question directe : qui dans votre équipe est responsable de l’intégrité du domain model aujourd’hui ?
Si la réponse est “personne” ou “tout le monde” — le domain model est déjà en train de se dissoudre dans la target architecture.
Le problème n’est pas que votre équipe ne sait pas faire du DDD. C’est que le dispositif ne protège pas le domain modeling de la pression du delivery. Le tech lead qui supervise les sprints ne peut pas simultanément maintenir la distance analytique nécessaire pour garder le problem space intact.
C’est précisément là où une intervention extérieure a de la valeur — non pas pour remplacer l’équipe, mais pour tenir le rôle que la structure interne ne peut pas tenir : maintenir l’intégrité du domain model pendant que le delivery avance.
C’est la première chose que je regarde dans un Architecture Assessment : est-ce que le domain model existe indépendamment du système actuel, ou est-il déjà une projection de l’existant.
Si vous êtes CEO plutôt que CTO et que vous préparez un projet de modernisation, cet article traite de la même dynamique du côté business →