dependency-injection - injection - inyeccion de dependencias spring
Contenedores de IoC y diseño impulsado por el dominio (3)
He estado buscando orientación para usar contenedores IoC en el diseño impulsado por dominio. El libro de Evan desafortunadamente no toca el tema. Las únicas pautas sustanciales que pude encontrar en Internet están aquí .
Muchos de los puntos de Malovic son de sentido común, pero me preocupan algunos de ellos. Sugiere que los contenedores de IoC se deben reservar para resolver solo los servicios y que usar un contenedor de IoC para resolver las dependencias de dominio es una mala idea. Sin embargo, él no respalda esta afirmación con ningún ejemplo. Él simplemente lo dice como una cuestión de hecho.
Luego continúa diciendo que mezclar contenedores y fábricas de IoC no tiene sentido. Esto parece contradecir su primer punto. Si, de hecho, las dependencias de dominio no deberían ser resueltas por un contenedor IoC, ¿cómo deberían resolverse entonces? El libro de Evan apunta claramente a las fábricas como la elección lógica.
Apreciaría cualquier aporte que tenga sobre el asunto. Soy un principiante cuando se trata de DDD e IoC. Estoy luchando para entender cómo IoC y DDD pueden funcionar juntos.
En mi opinión, tiene razón acerca de no usar el contenedor IoC en el modelo de dominio. Esa práctica me sigo a mí también. La idea básica es que los servicios pueden contener dependencias de infraestructura y, por lo tanto, es prudente burlarse de ellos. Las entidades de dominio no las tienen, por lo que no es importante simularlas (la codificación de las interfaces es una buena práctica).
Las fábricas para las entidades de dominio no deberían estar en un contenedor de IoC, pero las fábricas para servicios deberían. Básicamente, puede hacer referencia a fábricas de entidades en sus servicios. No es un acoplamiento muy apretado.
Se puede encontrar una buena lectura sobre IoC en la publicación de blog de Billy McCafferty "Dependency Injection 101"
Los contenedores de IOC son invaluables cuando se diseña un código que se puede probar por unidad y son ortogonales a DDD. Podrías crear tu propia implementación de patrones de fábrica y de constructor si quieres ... ¿por qué pasar por la molestia?
Absolutamente. Use un contenedor de IOC que sea lo suficientemente potente como para cumplir con sus requisitos específicos; ni mas ni menos.
Usamos DDD e inyección de dependencia (el patrón), pero no usamos un marco de inyección de dependencia.
Un problema con los marcos de inyección de dependencia populares es cómo separan la configuración en archivos XML. XML es un gran lenguaje de marcado. Cómo se convirtió en un lenguaje de configuración, nunca lo entenderé. El problema, por supuesto, es que debe ejecutar la aplicación antes de saber si todo está conectado correctamente. También es difícil ver qué código se usa donde. Si está utilizando interfaces, entonces la única referencia a una implementación estará en un archivo XML, que es más difícil de detectar. Y finalmente pierdes seguridad de tipo y genéricos. (Una vez vi un error horrible en la producción que habría sido capturado por el compilador si no hubiéramos estado usando XML.)
Debo señalar que no estoy diciendo que la inyección de dependencia sea mala. Es un patrón fundamental de buen diseño de objetos. Pero no hay absolutamente nada de malo en hacer el cableado en una fábrica.
En mis dos últimos proyectos, hemos eliminado grandes cantidades de "código" de archivos XML y en fábricas. Las fábricas están cableadas con servicios gestionados de contenedor (como conexiones JDBC, conexiones JMS, etc.). La aplicación se ha vuelto mucho más simple de entender, porque la fábrica es menos detallada que XML. Y como programador de Java, es mucho más fácil enlazar un programa usando espacio de control, en lugar de twiddling XML, y su IDE resaltará cuando haya roto algo.
En una prueba de integración, solo crea los objetos como lo harías en una fábrica.
es decir,
dbConnection = DatabaseConnectionFactory.connection();
serviceUnderTest = new PaymentProcessor(new CustomerRepository(connection));