Me estoy sumergiendo en el diseño impulsado por dominio y algunos de los conceptos que estoy encontrando tienen mucho sentido en la superficie, pero cuando pienso más en ellos, me pregunto si esa es realmente una buena idea.
El concepto de agregados, por ejemplo, tiene sentido. Crea pequeños dominios de propiedad para no tener que lidiar con todo el modelo de dominio.
Sin embargo, cuando pienso en esto en el contexto de una aplicación web, con frecuencia estamos presionando la base de datos para retirar pequeños subconjuntos de datos. Por ejemplo, una página solo puede enumerar el número de pedidos, con enlaces para hacer clic para abrir el pedido y ver sus ID de pedido.
Si estoy en lo correcto entendimiento agregados, me suelen utilizar el patrón de repositorio para devolver un OrderAggregate que contendría los miembros GetAll, GetByID, Delete, y Save. OK eso suena bien. Pero...
Si llamo a GetAll para enumerar todos mis pedidos, me parecería que este patrón requeriría que se devuelva la lista completa de información agregada, pedidos completos, líneas de pedido, etc. Cuando solo necesito un pequeño subconjunto de esa información (solo información del encabezado).
¿Me estoy perdiendo de algo? ¿O hay algún nivel de optimización que usarías aquí? No puedo imaginar que alguien abogue por devolver agregados enteros de información cuando no la necesite.
Ciertamente, uno podría crear métodos en su repositorio como GetOrderHeaders, pero eso parece anular el propósito de usar un patrón como repositorio en primer lugar.
¿Alguien puede aclarar esto para mí?
EDITAR:
Después de mucha más investigación, creo que la desconexión aquí es que un patrón de Repositorio puro es diferente de lo que la mayoría de la gente piensa que es un Repositorio.
Fowler define un repositorio como un almacén de datos que utiliza semántica de recopilación, y generalmente se mantiene en la memoria. Esto significa crear un gráfico de objeto completo.
Evans altera el repositorio para incluir raíces agregadas y, por lo tanto, el repositorio se amputa para admitir solo los objetos en un agregado.
La mayoría de las personas parecen pensar en los repositorios como objetos de acceso a datos glorificados, donde solo se crean métodos para obtener los datos que se desean. Esa no parece ser la intención descrita en los Patrones de arquitectura de aplicaciones empresariales de Fowler.
Aún otros piensan en un repositorio como una simple abstracción utilizada principalmente para facilitar las pruebas y las burlas, o para desacoplar la persistencia del resto del sistema.
Supongo que la respuesta es que este es un concepto mucho más complejo de lo que pensé al principio.