Pour qui ? Ma méthode Compétences Réalisations Avis Contact

Domain Driven Design

Comment appeler un chat... un chat

Photo principale: Domain Driven Design

Imagine un projet où tout le monde se comprend... ou presque. Dans la vraie vie, c'est rarement le cas.

Le Chaos Immobilier (Vécu)

Quand tu bosses sur un projet immobilier, tu entends parler de "prospect", "client", "visiteur", "demandeur", "vacancier"... et dans la base de données, tout ce beau monde est... un USER. Même les administrateurs de l'ERP.

Bonjour le chaos ! Parfois le "client" n'est pas la même personne selon la branche de la boite... Ajoute à ça des mandataires qui confondent "appartement au 5e étage" et "immeuble de 3 étages", si tes labels ou tes variables ne sont pas explicites tu obtiens un cocktail de gloubiboulga.

Ok, mais on fait quoi alors ?

C'est maintenant que DDD entre en scène, en français on pourrait dire "conception pilotée par le domaine".

C'est une méthodologie de conception logicielle qui met le métier au centre du développement. L'idée, c'est d'avoir un langage commun entre les développeurs et les experts métier, afin que le code reflète réellement les besoins de l'entreprise.

Pourquoi c'est important pour un CTO et pour les Dév ?

Compréhension

Réduire les incompréhensions entre développeurs et experts métier.

Qualité du Code

Avoir un code plus clair, mieux structuré et plus facile à maintenir.

Moins de Bugs

Éviter les bugs dus à des malentendus (l'appart au 5ème sur un immeuble de 3 étages).

Intégration

Faciliter l'intégration avec d'autres systèmes et plateformes.

Alors, imaginons maintenant le DDD dans les années 80 avec Tonton moustache et Tata moumoute... Mes 2 protagonistes ultra cliché. Tata moumoute rédige une lettre....

Recommandé AR
Expéditeur : Mme Ginette L. (alias Tata Moumoute)
Objet : Demande sur le "SuperMix Deluxe"
Destinataire :
Service Client
ÉlectroRêve 2000

Cher Service Client de l'ÉlectroRêve 2000,

Moi, Ginette L., femme au foyer passionnée d’électroménager et fervente utilisatrice de votre SuperMix 3000, je m’adresse à vous avec une requête bien précise.

Mon mari, Robert (qu’on appelle Tonton Moustache au bistrot), passe son temps à boire des bières en regardant le foot, pendant que moi, je m’efforce de cuisiner des plats dignes de Maïté. Or, j’ai entendu parler du SuperMix Deluxe en fabrication...

J'aimerai vous conseiller sur mes besoins pratiques [...] je vais procéder comme dans le livre qu’utilise le neveu de Robert, un certain "Domain-Driven Design" :

  1. Définition du Domaine :
    • Mon domaine principal est l’optimisation de la cuisine familiale.
    • Mon problème métier actuel : trop de temps passé à touiller les sauces pendant que Robert regarde Saint-Étienne perdre.
  2. Contexte Borné :
    • Je ne m’intéresse qu’à l’électroménager de cuisine.
    • Tout ce qui concerne la bière et le foot n'est pas pertinent pour mon contexte.
  3. Langage Omniprésent :
    • Nous allons parler en termes de blender, mixage, puissance moteur et non en "belle mécanique comme la R16".
  4. Spécifications Métier :
    • Mixer sans éclabousser.
    • Avoir un moteur puissant (pour le pot-au-feu).
    • Être facile à nettoyer.
  5. Interactions et Dépendances :
    • Si possible, un mixeur qui fait aussi du café.
    • Un silence relatif serait apprécié.

Je vous salue bien chaleureusement,
Ginette "Tata Moumoute" L.

Alors... l'analyse DDD du courrier donne quoi !

1. Domaine

L'électroménager, et plus précisément la cuisine.

2. Contexte Borné

On reste sur l’amélioration des tâches ménagères, sans interagir avec le loisir de Robert.

3. Langage Omniprésent

On parle mixage, puissance moteur, sans digressions sur le foot.

4. Spécifications Métier

Ce que doit faire le SuperMix Deluxe et pourquoi.

Mais que donnera le stockage des données sur l'Atari 2600 de la secrétaire :

categoryProduct = 'electroménager'

categoryProductInterestCustomer = 'cuisine'

requestPriority = 'haute' // parce que Tata Moumoute est pressée

senderName = 'Ginette_L'

recipientDepartment = 'Service_Client'

requestStatus = 'En_Cours_De_Traitement'

Grâce à son ordinateur révolutionnaire, la secrétaire peut ainsi classer le courrier avec un truc tout nouveau... une base de données. Waoooooo !

DDD Illustration

FAQ : Domain-Driven Design (DDD)

C'est l'idée fondamentale du DDD : utiliser le même vocabulaire précis dans les réunions, les documents, le code et la base de données. Si l'expert métier dit "Mandat Exclusif", le code ne doit pas dire "ContractType=1", mais bien "ExclusiveMandate". Cela élimine la traduction mentale et les erreurs.
Le DDD complet est complexe et souvent overkill pour un petit site vitrine. Cependant, les principes de base (parler le langage du métier, découper en contextes clairs) sont bénéfiques pour n'importe quel projet dès qu'il y a une logique métier un peu spécifique.
C'est la délimitation claire d'un sous-système où un modèle s'applique. Par exemple, le mot "Produit" n'a pas le même sens pour le service Marketing (image, pub) et pour le service Logistique (poids, dimension, stock). Le DDD sépare ces deux contextes pour éviter de créer un modèle géant et ingérable.

Partager cet article