Domain-Driven Design pour Applications Web
Le Domain-Driven Design (DDD), introduit par Eric Evans en 2003, est une approche de conception logicielle qui place le domaine métier au centre de chaque décision architecturale. Dans un écosystème web dominé par les frameworks et bibliothèques, DDD offre une boussole pour construire des applications dont la structure reflète fidèlement le langage et les processus du métier qu'elles servent.
Dans cet article, nous explorerons comment appliquer DDD dans un contexte web avec TypeScript, couvrant tant le niveau stratégique (Bounded Contexts, Context Maps) que tactique (Entities, Value Objects, Aggregates, Domain Events).
Ce que Vous Apprendrez
- DDD Stratégique : Bounded Contexts, Context Maps, Ubiquitous Language
- DDD Tactique : Entities, Value Objects, Aggregates, Repositories
- Domain Events et communication entre contextes
- Implémentation pratique en TypeScript
- Structure d'un projet Angular/Node.js avec DDD
- Collaboration avec les experts du domaine
DDD Stratégique
Le DDD stratégique s'occupe de la vue d'ensemble : comment découper un système complexe en parties gérables et comment ces parties communiquent entre elles.
Ubiquitous Language
L'Ubiquitous Language est le vocabulaire partagé entre développeurs et experts du domaine. Chaque terme a une signification précise et univoque au sein d'un contexte. Le code doit refléter ce langage.
Bounded Contexts
Un Bounded Context est une frontière explicite à l'intérieur de laquelle un modèle de domaine a une signification précise. Chaque Bounded Context possède son propre Ubiquitous Language, ses propres entités, et potentiellement sa propre base de données.
Context Map
La Context Map décrit les relations entre Bounded Contexts : Shared Kernel, Customer-Supplier, Anti-Corruption Layer, Published Language et Conformist.
DDD Tactique
Le DDD tactique fournit les building blocks pour implémenter le modèle de domaine : Entities (identité), Value Objects (immutables), Aggregates (unité de cohérence), Domain Events (faits survenus), Repositories (persistance) et Domain Services.
Règles des Aggregates
- L'accès externe se fait toujours via l'Aggregate Root
- Les invariants métier sont maintenus dans les limites de l'aggregate
- La persistance sauvegarde l'aggregate entier de manière atomique
- Les références entre aggregates se font par identité (ID)
- Les aggregates doivent être aussi petits que possible
Anti-Corruption Layer
Lors de l'intégration avec des systèmes externes, l'Anti-Corruption Layer (ACL) traduit les modèles externes dans le langage de notre domaine, protégeant le modèle interne de toute contamination.
Communication entre Bounded Contexts
Les Bounded Contexts communiquent entre eux via des Domain Events et un Event Bus. Cette communication asynchrone maintient les contextes découplés.
Erreurs Courantes dans l'Adoption de DDD
| Erreur | Conséquence | Remède |
|---|---|---|
| Commencer par le tactique sans le stratégique | Bounded Contexts mal définis | Toujours partir de l'analyse du domaine avec les experts |
| Aggregates trop grands | Conflits de concurrence, mauvaises performances | Suivre la règle : aggregates aussi petits que possible |
| Négliger l'Ubiquitous Language | Désalignement entre code et métier | Glossaire partagé, code review centrée sur les noms |
| DDD partout, même pour les CRUD simples | Sur-ingénierie | Appliquer DDD uniquement aux contextes avec logique complexe |
Quand Utiliser DDD
| Scénario | DDD Stratégique | DDD Tactique |
|---|---|---|
| Domaine simple | Utile pour la communication | Non nécessaire |
| Domaine modéré | Recommandé | Sélectif |
| Domaine complexe | Essentiel | Essentiel |
| Système legacy à moderniser | Essentiel | Progressif |
Conclusion
Le Domain-Driven Design n'est ni un framework ni une bibliothèque : c'est une façon de penser le logiciel en partant du problème métier plutôt que de la technologie. Appliqué à TypeScript et Angular, DDD apporte clarté dans la structure du projet et produit un code qui reflète fidèlement les processus métier.