Le domaine décrit votre métier ; c'est un ensemble de concepts et de logique qui pilote votre entreprise. Si vous suivez ce principe du Domain-Driven Design, (DDD), alors le domaine sera l'élément le plus important de votre application. Voici ce que nous explique Andras Nemes, un développeur Web suèdois sur la plate-forme .Net, dans le premier d'une série de dix articles sur la création d'un web service sur la plate-forme .Net basée sur les principes du Domain-Driven Design.
Dans une approche orientée par la technique, certains choix peuvent facilement affecter le domaine. En DDD cette orientation est inversée, le domaine est le composant le plus important de l'application et la technologie devient un détail d'implémentation qui peut varier. Et c'est ainsi que cela devrait être selon Andras. Votre domaine est une entité indépendante qui réagit aux exigences du métier, et les changements dans le domaine peuvent avoir des conséquences sur la technologie choisie.
Andras annonce clairement que son objectif n'est pas de couvrir tous les détails et les aspects du DDD, pour cela il se réfère au livre original du DDD écrit par Eric Evans. Il veut au contraire construire le squelette d'une solution .Net qui reprend les idées principales du DDD et il espère que celui-ci sera une base pour les projets DDD. Son ambition est que des développeurs complètement novices en DDD puissent aussi en bénéficier, c'est pour cela qu'il fournit des explications pour tous les concepts clés qu'il utilise.
Son objectif est une solution composée des couches suivantes :
- Infrastructure : une infrastructure de services pour répondre aux concepts transverses.
- Repository : une couche d'accès aux données et une technologie de persistence.
- Domain : la couche domaine avec les entités et la logique métier, le centre de l'application.
- Application services : une fine couche fournissant les actions des utilisateurs.
- Web : l'utilisateur de l'application.
A travers son exposé du DDD, Andras explique quelques-uns des principaux concepts tactiques du DDD, par exemple les entités, les value objects et les aggrégats, ainsi que des bonnes pratiques pour les utiliser. Il passe ensuite le reste de sa série d'articles à créer chaque couche qui constitue finalement l'application.
Au final, la conclusion d'Andras est que le DDD l'a aidé à réduire le couplage étroit que l'on retrouve souvent dans les solutions traditionnelles découpées en couches, la couche domaine étant maintenant au centre de l'application. Il a également réussi à cacher l'implémentation du référentiel, qui est la couche la plus axée sur la technologie, derrière une abstraction qui peut être remplacée.