DDD - Cómo implementar repositorios de alto rendimiento para buscar

Question

Tengo una pregunta sobre DDD y el patrón de repositorio.

Supongamos que tengo un repositorio de clientes para la raíz del agregado del cliente. Los métodos Get & Find devuelven el agregado totalmente poblado, que incluye objetos como Address, etc. Todo bien. Pero cuando el usuario busca un cliente en la interfaz de usuario, solo necesito un 'resumen' del agregado, solo un objeto plano con información resumida.

Una forma de lidiar con esto es llamar al método find en el repositorio de forma normal, y luego en la capa de aplicación asignar cada agregado de cliente a un DTO ClientSearchResult/CustomerInfo y enviarlos de vuelta al cliente.

Pero mi problema con esto es el rendimiento; cada agregado de Cliente puede requerir múltiples consultas para completar todas las asociaciones. Entonces, si mis criterios de búsqueda coinciden con 50 clientes, es un gran golpe en la base de datos para recuperar datos que ni siquiera voy a necesitar.

El otro problema es que puedo desear incluir datos resumidos sobre el cliente que se encuentren fuera del límite raíz agregado del Cliente, como la fecha del último pedido hecho, por ejemplo. El pedido tiene su propio agregado y, por lo tanto, para obtener la información del pedido del cliente, tendría que llamar al OrderRepository, lo que también degrada el rendimiento.

Así que ahora creo que me quedo con dos opciones:

1. Añadir un método Find adicional a la CustomerRepository que devuelve una lista de estos objetos de resumen, realice una consulta eficiente.

2. Crear un propósito construido CustomerInfoRepository de sólo lectura, que acaba de encontrar el método descrito en 1.

Pero ambas cosas siento que estoy yendo en contra de los principios de la DDD. Mis repositorios heredan de una base genérica: Repositorio donde T: IAggregateRoot. Estos objetos de información resumida no son agregados, y son de un tipo diferente a T, por lo que realmente el # 1 va en contra del diseño.

Quizás para el n. ° 2 crearía un SearchRepository abstracto sin la restricción IAggregateRoot?

Hay muchos escenarios similares en mi dominio.

¿Cómo implementaría este escenario?

Gracias, de Dave

actualización

Después de leer la respuesta de Theo, creo que voy a ir con la opción # 2 y crear un SearchRepository especializada dentro de mi infraestructura orientada a estos escenarios. La capa de aplicación (servicios WCF) puede llamar a estos repositorios que completan los DTO de resumen directamente en lugar de asignar entidades de dominio a DTO.

**** **** Actualización 2

Aunque hice esta hace un año pensé que acababa de añadir que desde entonces he descubierto CQRS que está orientada a la solución de este problema exacto.Udi Dahan (http://www.udidahan.com/) y Greg Young (http://codebetter.com/gregyoung/) han escrito mucho al respecto. Si está creando una aplicación distribuida con DDD, ¡CQRS es para usted!

Answer 1

Creo que solo desea mostrar información resumida. Estos bits de información resumida no son entidades u objetos de valor del modelo de dominio. Son solo información, nada más.

Es algo así como mostrar información de informes. Si me ocupo de tales cosas, no me apegaría al enfoque DDD puro. Sus opciones sugeridas son correctas, porque está haciendo su trabajo. La DDD no debe tratarse como un dogma. Pensar fuera de la caja. Aflojar un poco DDD.

Pero tenga en cuenta que solo está creando valores informativos fuera del modelo para mostrar el propósito. Por lo tanto, si un usuario selecciona un bit de información para realizar alguna operación con él (que se define en el modelo de dominio), debe extraer el identificador de los valores informativos y extraer el objeto/agregado de entidad/valor de un repositorio.

Recomiendo este video: Eric Evans: What I've learned about DDD since the book. Si lees su libro, realmente deberías ver el video completo. Preste mucha atención aproximadamente a las 30:00, donde el propio Eric Evans habla sobre los agregados y se refiere al problema que tiene actualmente.

Answer 2

lo haría:

1. devolver un objeto diferente, que representa una vista de mi objeto para mostrar, por ejemplo, Información del cliente.
2. Devuelve una tabla de datos. A menudo, un contenedor genérico es la forma más fácil y la mejor manera de hacerlo.

Si la T en su repositorio de base genérica es un cliente, entonces creo que está mal aplicar el concepto de raíces agregadas, aunque no soy una estricta Evansangelist. Diseñaría un repositorio para el Cliente que devolviera cualquier información que se agrupe de manera lógica o cómoda con el Cliente, incluidos los DataTables o los objetos de solo lectura que son vistas de los datos del Cliente.