¿Es DDD-Lite un lenguaje de patrones para la inyección de dependencias?

17

Me topé con la charla de Greg Young 7 razones por las cuales fallan los proyectos DDD, donde menciona algo que llama DDD-Lite a las 7:20.

Resumiendo, básicamente dice que algunos usan DDD como lenguajes de patrones (entidades, repositorios, objetos de valor, servicios, etc.) sin hacer nada más relacionado con DDD. Postula que el 60% o más de los modelos de dominio en .Net son DDD-Lite. Él piensa que DDD-Lite básicamente está construyendo un lenguaje en torno a la inyección de dependencia, algo que realmente no necesita hacer. Él dice o hacer DDD por completo o hacer algo más simple. De lo contrario, afirma que una persona está haciendo todo este trabajo para construir buenas abstracciones, pero sin ningún beneficio real.

Debo admitir que no sé tanto sobre DDD como me gustaría, y aún no he tratado de usarlo. Tampoco he leído el libro de Eric Evan tampoco. Estoy mucho más interesado en la inyección de dependencia y muchos, muchos libros y blogs sobre este tema usan términos y conceptos de referencia del libro DDD de Eric Evans. Aquí es donde he estado expuesto a los conceptos DDD. Los libros que he estado leyendo que hacen esto incluyen:

Inyección de dependencias en .NET
Microsoft .Net: Arquitectura de aplicaciones para la empresa
Desarrollo de aplicaciones Brownfield en .NET

Si uno quiere hacer una inyección de dependencia, ¿cuáles son las alternativas más simples en lugar de hacer "DDD-Lite"? Me parece que construir buenas abstracciones es bastante útil, independientemente de si uno está usando conceptos de DDD de una manera "DDD-Lite". (vea las publicaciones de blog de Mark Seemann: Las interfaces no son abstracciones y Hacia mejores abstracciones ). Me cuesta creer que todos los que hacen la inyección de dependencia también estén haciendo (o necesiten hacer) DDD completo. ¿De alguna manera entendí mal el argumento de Greg Young sobre DDD-Lite?

— Mate
fuente

15

La inyección de dependencia y DDD son dos conceptos disjuntos. Hacer la inyección de dependencia no requiere hacer DDD ni DDD requiere inyección de dependencia.

Muchos proyectos DDD fallan porque escogen los patrones pero descuidan el proceso detrás de DDD. No se toman el tiempo para extraer las reglas comerciales. No se concentran en el modelo de dominio y en abstracciones cuidadosas. No establecen un idioma ubicuo.

En resumen: supongo que es un malentendido

— saintedlama
fuente

44

+1 Los patrones descritos en el libro de Evans siguen siendo valiosos en un contexto mucho más amplio, siempre y cuando se entienda que aplicarlos de forma aislada no lo convierte en DDD.

— Mark Seemann el

1

Sí, me doy cuenta de DI! = DDD. @ MarkSeemann, entonces el argumento de Greg parece ser que la gente dice que están haciendo DDD cuando no lo están. Está bien lo entiendo. Pero también argumenta que el uso de abstracciones como las que se encuentran en DDD (agregados, repositorios, entidades de dominio, objetos de valor, servicios, etc.) son innecesarios si se usan solo para admitir una arquitectura inyectada de dependencia. Esa es la parte que no entiendo (qué tiene de malo). Tal vez ese sea el argumento del hombre de paja , ya que el uso de tales cosas no es solo para "construir un lenguaje alrededor de la inyección de dependencia".

— Matt

3

Greg es parcialmente correcto: los patrones especiales en DDD no están particularmente relacionados con DI. Sin embargo, en mi libro tomé parte de la terminología, particularmente la definición de Entidad vs. Objeto de valor vs. Servicio porque es importante entender qué inyectar dónde. Sin embargo, tanto esta terminología como otros patrones como Repository y Factory son mucho más antiguos que el libro DDD, por lo que decir que tales cosas son innecesarias fuera de DDD me parece incorrecto. Puede depender de cómo se defina DDD.

— Mark Seemann el

2

Apuesto a que Greg se refiere a la aplicación simple si se trata de un subconjunto de patrones de diseño impulsado por dominio en lugar del enfoque DDD completo. El término DDD-Lite se refiere implícitamente al libro http://www.infoq.com/minibooks/domain-driven-design-quickly que solía ser popular entre los novatos DDD, pero muchas de las cosas se pierden al enfocarse solo en el Patrones de diseño de modelado local.

Aunque la inyección de dependencia se considera algo bueno, no existe una fuerte correlación entre DDD y DI.

— ZioBrando
fuente