Patrones de diseño: Fábrica y Repositorio

Question

me han preguntado si el patrón de la fábrica y la patrón Repositorio se keened a ir de la mano en un proyecto Domain Driven Design?

La razón por la que pido es la forma en que estoy haciendo esto es así:

interfaz gráfica de usuario -> ClassFactory -> ClassProduct (es decir en el modelo de dominio) -> ClassProductRepository -> origen de datos

La interfaz gráfica de usuario llama a ClassFactory para separar la GUI de la lógica comercial. ClassProduct llama al ClassProductRepository para separar la lógica comercial de la fuente de datos.

¿Es este un enfoque incorrecto al usar estos patrones de diseño con Domain Driven Design? Si es así, por favor diga su opinión sobre este tema.

Answer 1

Su en el camino correcto. Como Chad señaló, querrá usar un patrón de separación de interfaz GUI como una capa adicional entre su dominio y la UI. MVC, MVP, Presentation Model, etc. son patrones bien establecidos y bien documentados para la separación de UI. Martin Fowler excelente PoEAA cubre muchos de ellos

En cuanto a su pregunta principal. Sí. Las fábricas y los repositorios funcionan muy bien juntos. De hecho, Evans sugiere en DDD que en algunos casos puede delegar la responsabilidad de la creación de objetos desde su repositorio a sus clases de fábrica cuando reconstruye objetos desde el almacén de datos.

client <=> repository -> factory 
       | 
       v 
      database 

1. el cliente solicita un objeto de el repositorio.
2. El repositorio consulta la base de datos.
3. El repositorio envía datos brutos a la fábrica .
4. El objeto devuelve la fábrica.

Una simplificación excesiva, pero se entiende la idea. Un punto que Evans no menciona (pero que cubre Fowler) es la inyección de dependencia. A medida que la complejidad de su dominio continúa creciendo, es posible que desee considerar pasar a un contenedor IoC para administrar los ciclos de vida de los objetos.

Answer 2

Sugeriría apegar a MVC como un enfoque genérico para separar su lógica de negocios de su vista y su controlador. Este ha sido un enfoque bien documentado y bien estudiado, aunque es el mejor que tenemos actualmente.

Sin embargo, parece que está tratando de usar el patrón solo por el motivo de usar el patrón. Esto es bueno para aprender, pero en la mayoría de los sistemas de aplicaciones he visto que los patrones que ha descrito no existen y funciona un enfoque más simple o que es una pesadilla mantener.

Consulte mi respuesta anterior a una pregunta similar como esta, que tiene un video que puede ayudarlo en su diseño en el futuro.
Linky