Compartir a través de

Aplicar enfoques de CQRS y CQS en un microservicio DDD en eShopOnContainers

Sugerencia

Este contenido es un extracto del libro electrónico, ".NET Microservices Architecture for Containerized .NET Applications" (Arquitectura de microservicios de .NET para aplicaciones de .NET contenedorizadas), disponible en Documentación de .NET o como un PDF descargable y gratuito que se puede leer sin conexión.

Descargar PDF

Miniatura de la portada del libro electrónico 'Arquitectura de microservicios de .NET para aplicaciones .NET contenedorizadas'.

El diseño del microservicio de ordenación en la aplicación de referencia eShopOnContainers se basa en los principios de CQRS. Sin embargo, usa el enfoque más sencillo, que simplemente separa las consultas de los comandos y usa la misma base de datos para ambas acciones.

La esencia de esos patrones y el punto importante aquí es que las consultas son idempotentes: independientemente de cuántas veces consulte un sistema, el estado de ese sistema no cambiará. En otras palabras, las consultas están libres de efectos secundarios.

Por lo tanto, podría usar un modelo de datos de "lectura" distinto al modelo de dominio de "escritura" de lógica transaccional, aunque los microservicios de ordenación usen la misma base de datos. Por lo tanto, se trata de un enfoque simplificado de CQRS.

Por otro lado, los comandos, que desencadenan transacciones y actualizaciones de datos, cambian el estado en el sistema. Debe tener cuidado con los comandos cuando trabaje con la complejidad y las reglas de negocio cambiantes. Aquí es donde desea aplicar técnicas DDD para tener un sistema mejor modelado.

Los patrones DDD presentados en esta guía no se deben aplicar universalmente. Introducen restricciones en el diseño. Estas restricciones proporcionan ventajas como una mayor calidad a lo largo del tiempo, especialmente en comandos y en otro código que modifica el estado del sistema. Sin embargo, esas restricciones agregan complejidad con menos ventajas para leer y consultar datos.

Uno de estos patrones es el patrón agregado, que examinamos más en secciones posteriores. Brevemente, en el patrón Aggregate, se tratan muchos objetos de dominio como una sola unidad como resultado de su relación en el dominio. Es posible que no siempre obtenga ventajas de este patrón en las consultas; puede aumentar la complejidad de la lógica de consulta. En el caso de las consultas de solo lectura, no se obtienen las ventajas de tratar varios objetos como un único agregado. Solo se obtiene la complejidad.

Como se muestra en la figura 7-2 de la sección anterior, esta guía sugiere el uso de patrones DDD solo en el área transaccional/actualizaciones del microservicio (es decir, como desencadenan los comandos). Las consultas pueden seguir un enfoque más sencillo y deben separarse de los comandos, siguiendo un enfoque de CQRS.

Para implementar el "lado de consultas", puede elegir entre varios enfoques, desde un ORM completo como EF Core, proyecciones de AutoMapper, procedimientos almacenados, vistas, vistas materializadas o un micro ORM.

En esta guía y en eShopOnContainers (específicamente el microservicio de ordenación) hemos elegido implementar consultas rectas mediante un micro ORM como Dapper. Esta guía le permite implementar cualquier consulta basada en instrucciones SQL para obtener el mejor rendimiento, gracias a un marco ligero con poca sobrecarga.

Cuando se usa este enfoque, las actualizaciones del modelo que afectan a cómo se conservan las entidades en una base de datos SQL también necesitan actualizaciones independientes de las consultas SQL usadas por Dapper o cualquier otro enfoque independiente (no EF) para realizar consultas.

Los patrones CQRS y DDD no son arquitecturas de nivel superior

Es importante comprender que los patrones CQRS y la mayoría de los patrones DDD (como las capas DDD o un modelo de dominio con agregados) no son estilos arquitectónicos, sino solo patrones de arquitectura. Los microservicios, SOA y la arquitectura controlada por eventos (EDA) son ejemplos de estilos arquitectónicos. Describen un sistema de muchos componentes, como muchos microservicios. Los patrones CQRS y DDD describen algo dentro de un único sistema o componente; en este caso, algo dentro de un microservicio.

Los diferentes contextos delimitados (CD) emplearán distintos patrones. Tienen diferentes responsabilidades y que conducen a diferentes soluciones. Vale la pena destacar que forzar el mismo patrón en todas partes conduce a un fracaso. No use patrones CQRS y DDD en todas partes. Muchos subsistemas, contextos delimitados o microservicios son más sencillos y se pueden implementar más fácilmente mediante servicios CRUD simples o mediante otro enfoque.

Solo hay una arquitectura de aplicación: la arquitectura del sistema o la aplicación de un extremo a otro que está diseñando (por ejemplo, la arquitectura de microservicios). Sin embargo, el diseño de cada Contexto Delimitado o microservicio dentro de esa aplicación refleja sus propios compromisos y decisiones de diseño internas en el nivel de patrones arquitectónicos. No intente aplicar los mismos patrones arquitectónicos que CQRS o DDD en todas partes.

Recursos adicionales

Siguiente anterior