DDD-Lite est-il un langage de modèle pour l'injection de dépendances?

17

Je suis tombé sur le discours de Greg Young 7 Reasons Why DDD Projects Fail où il mentionne quelque chose qu'il appelle DDD-Lite à 7h20.

En résumé, il dit essentiellement que certains utilisent DDD comme langages de modèle (entités, référentiels, objets de valeur, services, etc.) sans rien faire d'autre lié à DDD. Il postule que 60% ou plus des modèles de domaine en .Net sont DDD-Lite. Il pense que DDD-Lite est en train de construire un langage autour de l'injection de dépendance, ce que vous n'avez pas vraiment besoin de faire. Il dit soit de faire DDD entièrement, soit de faire quelque chose de plus simple. Sinon, il prétend qu'une personne met en avant tout ce travail pour construire de bonnes abstractions, mais sans aucun avantage réel.

Je dois admettre que je ne connais pas autant le DDD que je le souhaiterais, et je n'ai pas encore essayé de l'utiliser. Je n'ai pas non plus lu le livre d'Eric Evan non plus. Je m'intéresse beaucoup plus à l'injection de dépendance et de nombreux livres et blogs sur ce sujet utilisent des termes et des concepts de référence du livre DDD d'Eric Evans. C'est là que j'ai été exposé aux concepts DDD. Les livres que j'ai lus qui font cela incluent:

  • Injection de dépendances dans .NET
  • Microsoft .Net: Architecture d'applications pour l'entreprise
  • Développement d'applications Brownfield dans .NET

Si l'on veut faire l'injection de dépendance, quelles sont les alternatives plus simples que de faire "DDD-Lite?" Il me semble que la construction de bonnes abstractions est très utile, peu importe si l'on utilise les concepts de DDD de manière "DDD-Lite". (voir les articles de blog de Mark Seemann: les interfaces ne sont pas des abstractions et vers de meilleures abstractions ). J'ai du mal à croire que tout le monde qui fait de l'injection de dépendance fait également (ou doit faire) un DDD à part entière. Ai-je mal compris l'argument de Greg Young à propos de DDD-Lite?

.net dependency-injection domain-driven-design abstraction Mat
la source

Réponses:

15

L'injection de dépendance et DDD sont deux concepts disjoints. Faire l'injection de dépendance ne nécessite pas de faire DDD ni DDD nécessite l'injection de dépendance.

De nombreux projets DDD échouent car ils choisissent les modèles mais négligent le processus derrière DDD. Ils ne prennent pas le temps d'extraire des règles métier. Ils ne se concentrent pas sur le modèle de domaine et sur des abstractions prudentes. Ils n'établissent pas un langage omniprésent.

En bref: je suppose que c'est un malentendu

saintedlama
la source
4
+1 Les modèles décrits dans le livre d'Evans sont toujours utiles dans un contexte beaucoup plus large - tant que l'on comprend que les appliquer isolément ne fait pas de DDD.
Mark Seemann
1
Oui je réalise DI! = DDD. @MarkSeemann, donc l'argument de Greg semble être que les gens disent qu'ils font du DDD alors qu'ils ne le font pas. D'accord, je comprends. Mais il soutient également que l'utilisation d'abstractions telles que celles trouvées dans DDD (agrégats, référentiels, entités de domaine, objets de valeur, services, etc.) ne sont pas nécessaires si elles sont utilisées uniquement pour prendre en charge une architecture injectée en dépendance. C'est la partie que je ne comprends pas (quel mal avec ça). Peut-être que tel est l' argument de l'homme de paille , car utiliser de telles choses ne consiste pas seulement à "construire un langage autour de l'injection de dépendance".
Matt
3
Greg a partiellement raison: les modèles spéciaux de DDD ne sont pas particulièrement liés à DI. Cependant, dans mon livre, j'ai repris une partie de la terminologie, en particulier la définition de l'entité contre l'objet de valeur contre le service, car il est important de comprendre quoi injecter où. Cependant, cette terminologie ainsi que d'autres modèles comme Repository et Factory sont beaucoup plus anciens que le livre DDD, donc dire que de telles choses sont inutiles en dehors de DDD me semble incorrect. Cela peut dépendre de la façon dont vous définissez réellement DDD.
Mark Seemann
2

Je parie que Greg fait référence à l'application simple si un sous-ensemble de modèles de conception pilotée par domaine au lieu de toute l'approche DDD. Le terme DDD-Lite se réfère implicitement au livre http://www.infoq.com/minibooks/domain-driven-design-quickly qui était autrefois populaire parmi les débutants DDD, mais il manque beaucoup l'image en se concentrant uniquement sur le modèles de conception de modélisation locale.

Bien que l'injection de dépendance soit considérée comme une bonne chose, il n'y a pas de forte corrélation entre DDD et DI.

ZioBrando
la source