domain driven design - ¿Cómo encajan las vistas de la base de datos de solo lectura en el patrón del repositorio?
domain-driven-design repository-pattern (3)
Creo que está bien tener un repositorio separado como "CustomerOrdersOnHoldRepository". La interfaz del repositorio reflejará el hecho de que los objetos son de solo lectura (al no definir el método Save / Add / MakePersistent).
De Cómo escribir un repositorio :
... Pero hay otra estrategia que me gusta bastante: múltiples repositorios. En nuestro ejemplo de pedido no hay ninguna razón por la que podamos tener dos Repositorios: AllOrders y SurchargedOrders. AllOrders representa una lista que contiene cada orden en el sistema, SurchargedOrders representa un subconjunto de él.
No llamaría objeto devuelto una raíz Aggrgate. Los agregados son para la consistencia, el intercambio de datos y los ciclos de vida. Tus objetos no tienen ninguno de estos. Parece que tampoco pueden clasificarse como objetos de valor (''característica o atributo''). Solo son clases independientes.
Ejemplo: Su base de datos tiene una vista SQL llamada "CustomerOrdersOnHold". Esta vista devuelve una mezcla filtrada de campos específicos de datos de clientes y pedidos. Debe obtener datos de esta vista en su aplicación. ¿Cómo encaja el acceso a dicha vista en el patrón del repositorio? ¿Crearía un "CustomerOrdersOnHoldRepository"? ¿Una vista de solo lectura como esta se considera una raíz agregada?
Preferiría separar el repositorio de lectura, preferiblemente, incluso cambiar su nombre a Finder o Reader, el repositorio está destinado para el uso del dominio, no para consultar datos de solo lectura, puede consultar este artículo y this explica el uso del repositorio de formularios separados por el Finder. .
Recomendaría también la separación del modelo de lectura de la arquitectura de modelo de escritura CQRS y there
Esta arquitectura le permite separar el modelo de lectura del modelo de escritura incluso en términos de almacenamiento de datos y el uso de la fuente de eventos.
Para una solución intermedia, puede utilizar algunos conceptos de CQRS sin la complejidad de separar la base de datos simplemente separando el repositorio de los buscadores, lea esta post
para una muestra de este tipo de solución (use la misma base de datos pero separando los buscadores de los repositorios) verifique esta muestra
Sus datos de solo lectura se considerarán Objetos de valor en el mundo de DDD.
Por lo general, coloco los métodos de acceso para los objetos de valor en los repositorios existentes hasta que tenga sentido crear un repositorio separado. Es similar a un método que podría devolver una lista estática de estados que se utilizarán en una forma de dirección:
IAddressRepository
{
Address GetAddress(string addressID);
List<string> GetStates(string country);
}