¿Cómo implementar el lado de consulta de CQRS en DDD?

Question

Implementé el lado del comando de DDD utilizando el modelo de dominio y los repositorios, pero ¿cómo implemento el lado de la consulta?

¿Creé un modelo de dominio completamente nuevo para la interfaz de usuario, y dónde se guarda esto en la estructura del proyecto ... en la capa de dominio, la capa de interfaz de usuario, etc.?

Además, ¿qué uso como mecanismo de consulta, creo nuevos repositorios específicamente para los objetos de dominio UI, algo que no sean repositorios, o algo más?

Answer 1

Según mi comprensión de CQRS, crearía un conjunto de DTO que cumplen los requisitos de las pantallas de la interfaz de usuario o las aplicaciones que pueden necesitar consumirlas.

El hecho de que exista en el proyecto se basa en los requisitos, ya que dependería de exponer estos DTO a través de servicios web. En cuyo caso yo no lo pondría en la Capa Web, sino en la capa de Aplicación o en una capa de Fachada dedicada.

Luego, tendría un repositorio de solo lectura o una capa de acceso a datos que llene los DTO directamente. Creo que el lado de Query debe optimizarse para el rendimiento de lectura, en cuyo caso las consultas directas/procedimientos almacenados en vistas o tablas de base de datos y SqlDataReaders harían el mejor trabajo aquí. Pero definitivamente valdría la pena abstraer este acceso detrás de una interfaz para que pueda agregar una implementación en caché más adelante en la pista.

Si está utilizando un ORM y desea asignar sus Entidades de Dominio a los DTO, entonces podría tener un QueryRepository genérico que tenga métodos que tomen una especificación IS o una construcción similar para definir sus consultas, luego un objeto DtoAssembler para crear la Dtos de tus objetos de Dominio. Luego tenga una implementación con un objeto de primera clase para cada una de las consultas que va a realizar.

Aquí está un ejemplo bastante artificial, pero espero que te da una idea.

 public interface ISpecification<T> 
     { 
      Expression<Func<T, bool>> Predicate { get; } 

     } 

     public class ActiveCustomersSpecification : ISpecification<Customer> 
     { 
      private Expression<Func<Customer, bool>> predicate; 
      public ActiveCustomersSpecification() 
      { 
       predicate = c => c.IsActive; 
      } 
      #region ISpecicfication<Customer> Members 

      public Expression<Func<Customer, bool>> Predicate 
      { 
       get { return predicate; } 
      } 

      #endregion 
     } 

     public interface IQueryRepository<T> 
     { 
      IQueryable<T> GetQuery(ISpecification<T> specification); 

      IEnumerable<T> FindAllBy(ISpecification<T> specification); 
     } 



public class CustomerDtoAssembler 
    { 
     public CustomerDto AssembleFrom(Customer customer) 
     { 
      var customerDto = new CustomerDto 
      { 
       Id = customer.Id 
      }; 

      return customerDto; 
     } 
    } 

Answer 2

creo willbt le ha dado una muy buena starting point.

Yo agregaría que si opta por continuar utilizando el ORM como la estrategia de acceso a datos para consultas, sería recomendable que considere la definición de una estrategia de búsqueda adaptada a los datos que espera que necesite acceder (Estoy pensando específicamente en NHibernate aquí, por cierto). Lo que esto significa es que usted puede decidir si desea perezoso carga o ansiosos-cargar los objetos y colecciones asociadas a un objeto particular Aggregate Root.

El NCommon project de Ritesh Rao ofrece una excelente demostración (en curso) de cómo definir una estrategia de búsqueda diferente para diferentes propósitos.

Ritesh explains it really bien en su blog.

Seguir adelante y echar un vistazo a la fuente:

• aquí es the IFetchingStrategy interface
• y esto demuestra the use of fetching strategies in a unit test

En los Repository_For_Uses_Registered_Fetching_Strategies 'prueba la llamada a

NHRepository<Order>().For<NHRepositoryTests>() 

... causa la fe las estrategias de tching registradas contra la clase NHRepositoryTests que se utilizarán, y por lo tanto, se cargarán ansiosamente los artículos de pedido y los productos sin interferir con las configuraciones de asignación de NHibernate.