Le problème que vous connaissez sans le nommer

Vous avez probablement déjà vécu cette situation. Vous commandez une application à un prestataire. Vous passez des heures en réunion à expliquer comment vous travaillez. Trois mois plus tard, l'application est livrée. Et elle ne correspond pas à votre réalité.

Pas parce que le prestataire est incompétent. Mais parce qu'entre ce que vous avez dit et ce que le développeur a compris, il y a eu une perte de traduction. Le métier que vous avez décrit pendant des heures s'est transformé en tables SQL génériques, en formulaires standards, en workflows génériques. Votre application est techniquement correcte, mais elle ne vous ressemble pas. Pire, elle vous force à adapter votre façon de travailler à l'outil, au lieu que l'outil épouse votre métier.

Le Domain-Driven Design en une phrase

Le Domain-Driven Design (DDD), théorisé par Eric Evans en 2003, c'est une approche de conception logicielle qui place votre métier au centre de l'architecture de l'application. Pas la technologie. Pas la base de données. Pas le framework. Votre métier, avec ses concepts, ses règles, son vocabulaire.

Concrètement, le DDD impose une discipline : avant d'écrire une ligne de code, on modélise le domaine métier. On identifie les entités (lot, DPGF, devis, chantier), les règles qui les régissent, les processus qui les transforment. Ce modèle devient le cœur de l'application.

Pour le décideur : Le DDD garantit que l'application pense comme vous pensez. Quand vous dites "lot", l'application comprend "lot" exactement comme vous l'entendez, pas comme un développeur l'imagine.

Pourquoi c'est radicalement différent

Dans une approche classique, le développeur traduit le cahier des charges en tables de base de données. Le métier est "aplati" : un lot devient une ligne avec des colonnes, un devis une autre ligne avec un statut stocké en chaîne de caractères, une quantité un simple nombre. Les règles métier se retrouvent dispersées dans des validations de formulaires, des contraintes SQL, ou pire, dans des commentaires de code.

Avec le DDD, on commence par modéliser le domaine. Un lot n'est pas une ligne dans un tableau, c'est un objet avec un comportement : il sait se sous-diviser, il sait calculer son prix, il refuse d'accepter un métré incohérent. Les règles métier sont protégées par le type lui-même.

Exemple concret BTP
Sans DDD : Un champ "statut" qui peut valoir n'importe quelle chaîne. Rien n'empêche de passer un devis de "envoyé" à "brouillon" en base, même si ça n'a aucun sens métier.

Avec DDD : Un objet "Devis" avec des états explicites (Brouillon, Envoyé, Accepté, Refusé) et des transitions autorisées. Un devis envoyé ne peut pas redevenir brouillon. C'est le code qui protège vos règles, pas un commentaire dans la doc.

Les 4 concepts clés du DDD

1. Le langage ubiquitaire

Un vocabulaire unique et partagé entre métier et tech. Si vous appelez ça un "lot technique", le code l'appelle aussi "lot technique". Pas "category" ou "item_group". Cette discipline élimine 80% des malentendus projet.

2. Les bounded contexts

Chaque sous-domaine métier a ses propres règles. Un "client" en phase commerciale n'a pas la même signification qu'un "client" en phase de facturation. Le DDD reconnaît explicitement ces frontières au lieu de les gommer.

3. Les agrégats

Des grappes d'objets qui évoluent ensemble. Un DPGF avec ses postes, ses lots, ses quantités forment un agrégat : ils se modifient de façon cohérente, jamais isolément.

4. Les services de domaine

Les opérations métier qui ne peuvent pas appartenir à une seule entité (calcul d'un décompte général définitif, validation d'une offre). Elles sont explicites, nommées, testées.

Ce que ça change pour votre projet

Moins de malentendus

Le vocabulaire est partagé dès le premier atelier. Les erreurs de traduction entre cahier des charges et code disparaissent. Les équipes métier peuvent relire le code et reconnaître leur univers.

Une application qui évolue avec vous

Quand votre métier évolue (nouvelle réglementation, nouveau processus, nouveau type de lot), on sait exactement où intervenir dans le code. Pas besoin de déchiffrer 50 000 lignes : le domaine est modélisé explicitement.

Des règles métier protégées

Contraintes réglementaires, processus de validation, règles de calcul : tout est intégré dans le code, au niveau des types. Un développeur ne peut pas contourner une règle par accident, le code refuse de compiler.

Une maintenance moins coûteuse

Les bugs de régression chutent drastiquement. Les refactorings deviennent sûrs. Les nouvelles fonctionnalités s'ajoutent sans casser l'existant. Sur une application métier qui va vivre 10 ans, c'est un ROI massif.

Quand appliquer le DDD ?

Le DDD est pertinent quand votre application porte une complexité métier réelle : plus de 5 entités métier, des règles de gestion sophistiquées, un vocabulaire spécifique à votre secteur, une durée de vie supérieure à 3 ans. Pour un simple CRUD, c'est overkill. Pour une application métier BTP, immobilier ou ingénierie, c'est quasi indispensable.

En résumé : Le DDD met votre expertise métier au cœur de l'application. Le résultat : un outil qui vous ressemble, qui respecte vos règles, et qui évolue avec vous sans dette technique. Chez Agatta, on applique le DDD systématiquement sur les applications métier complexes : c'est la garantie que votre logiciel ne vieillira pas.