Le DDD (Domain-Driven Design, ou conception pilotée par le domaine) est une approche de conception logicielle qui place le métier au centre : le code reproduit fidèlement les concepts, les règles et le vocabulaire du domaine (assurance, logistique, paiement), construits en dialogue étroit avec les experts métier. L'approche a été formalisée par Eric Evans dans un livre paru en 2003.
Deux idées en sont le cœur. Le langage omniprésent (ubiquitous language) : développeurs et experts utilisent les mêmes mots, et ces mots se retrouvent dans le code. Les contextes délimités (bounded contexts) : un grand système est découpé en zones cohérentes, chacune avec son propre modèle ; un « client » n'a pas la même définition pour la facturation et pour le support.
Le DDD propose aussi des briques tactiques (entités, agrégats, objets valeur, événements de domaine). Il est utile pour les logiciels à forte complexité métier et sert souvent de guide pour découper une application en microservices.
Pourquoi ça compte quand on recrute
Beaucoup de développeurs citent le DDD ; peu l'ont appliqué au-delà du nommage des dossiers. En entretien, demandez comment le candidat a identifié les contextes délimités d'un projet et comment il travaillait avec les experts métier. Le signal fort : il parle du métier avant de parler de patterns. C'est une compétence clé pour un architecte ou un tech lead sur un logiciel métier complexe.