Contenedores IoC y diseño impulsado por dominio

Question

He estado buscando instrucciones 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 son here.

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 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.

Agradecería cualquier comentario que tenga al respecto. Soy un principiante cuando se trata de DDD e IoC. Estoy luchando para entender cómo IoC y DDD pueden funcionar juntos.

Answer 1

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 IoC, pero las fábricas para los servicios deberían. Básicamente, puede hacer referencia a fábricas de entidades en sus servicios. No es un acoplamiento muy apretado.

Buena lectura sobre la COI se puede encontrar en Billy McCafferty's blog post "Dependency Injection 101"

Answer 2

contenedores COI son de gran valor en el diseño de código de unidad comprobable 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.

Answer 3

Usamos DDD y la inyección de dependencia (el patrón), pero no usamos un marco de inyección de dependencia.

Un problema con los populares frameworks de inyección de dependencias 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 usado 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 unir un programa usando el espacio de control, en lugar de twiddling XML, y su IDE resaltará cuando haya roto algo.

En una prueba de integración, simplemente cree los objetos como lo haría en una fábrica.

es decir,

dbConnection = DatabaseConnectionFactory.connection();  
serviceUnderTest = new PaymentProcessor(new CustomerRepository(connection));