Domain Driven Design

Popularisée par le livre Domain-Driven Design: Tackling Complexity in the Heart of Software (2003) d'Eric Evans, le Domain-Driven Design (DDD) est une approche de développement logiciel axée sur la modélisation d'un domaine d'activité complexe.
Le DDD a émergé en réponse à la complexité croissante des systèmes logiciels au début des années 2000.
À cette époque, de nombreuses entreprises et développeurs se heurtaient à des difficultés majeures dans la conception de systèmes complexes, souvent causées par une déconnexion entre :

• Les experts métier, qui maîtrisent les besoins, les règles et les processus du domaine d'activité
• Les développeurs, responsables de traduire ces besoins en code logiciel.

Le DDD vise à combler ce fossé en instaurant une collaboration étroite entre ces deux groupes, tout en fournissant des outils et des concepts pour mieux structurer et modéliser les systèmes complexes.

1. Focus sur le domaine et la logique métier : Le DDD met l'accent sur une compréhension approfondie et une modélisation rigoureuse du domaine d'activité. Cette démarche implique une collaboration étroite entre les experts métier et les développeurs pour créer un modèle commun.
   Ce modèle guide la conception et le développement du système en restant aligné sur les besoins réels du métier.
2. Langage ubiquitaire : Un langage ubiquitaire (ou universel) est un langage commun, partagé par les développeurs et les experts métier. Ce langage est utilisé dans les discussions, la documentation, ainsi que dans le code.
   En réduisant les malentendus et en harmonisant la communication, ce langage facilite l'alignement du développement sur les objectifs métiers.
3. Modélisation et conception orientées autour du domaine : Plutôt que de se concentrer sur les aspects techniques (comme les bases de données ou les interfaces utilisateur), le DDD préconise de modéliser d'abord le domaine.
   Cela implique l'identification des entités, valeurs, services, agrégats, et objets de valeur pour représenter les concepts métier de manière précise et utile.
4. Isolation des domaines : Les systèmes complexes peuvent être décomposés en plusieurs sous-domaines, chacun correspondant à une partie distincte du métier. Le DDD encourage à développer des modèles distincts pour chaque sous-domaine, facilitant ainsi la gestion de la complexité. Ces sous-domaines peuvent être classifiés comme :
   • Domaine principal (Core Domain) : Le cœur stratégique du système, apportant une valeur ajoutée unique à l'entreprise.
   • Domaines génériques : Des composants standards pouvant être réutilisés.
   • Domaines auxiliaires : Des aspects moins critiques mais nécessaires au bon fonctionnement du système.
5. Architecture orientée domaine : Le modèle de domaine influence directement la conception de l'architecture du système, y compris :
   • L'organisation du code (par exemple, par modules ou contextes limités).
   • Les interactions entre les composants.
   • L'intégration avec des systèmes tiers.

Cette approche garantit que l'architecture reste cohérente avec les besoins métier, plutôt que de répondre uniquement à des impératifs techniques.