Compartir a través de

Aplicación de patrones CQRS y DDD simplificados en un microservicio

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'.

CQRS es un patrón arquitectónico que separa los modelos para leer y escribir datos. El término relacionado Separación de comando-consulta (CQS) fue definido originalmente por Bertrand Meyer en su libro Object-Oriented Construcción de software. La idea básica es que puede dividir las operaciones de un sistema en dos categorías separadas claramente:

  • Consultas. Estas consultas devuelven un resultado y no cambian el estado del sistema y están libres de efectos secundarios.

  • Comandos. Estos comandos cambian el estado de un sistema.

CQS es un concepto sencillo: se trata de métodos dentro del mismo objeto, ya sea consultas o comandos. Cada método devuelve el estado o muta, pero no ambos. Incluso un único objeto de patrón de repositorio puede cumplir con CQS. CQS se puede considerar un principio fundamental para CQRS.

La segregación de responsabilidades de comandos y consultas (CQRS) fue introducida por Greg Young y promocionada fuertemente por Udi Dahan y otros. Se basa en el principio CQS, aunque es más detallado. Se puede considerar un patrón basado en comandos y eventos, además de opcionalmente en mensajes asincrónicos. En muchos casos, CQRS está relacionado con escenarios más avanzados, como tener una base de datos física diferente para lecturas (consultas) que para escrituras (actualizaciones). Además, un sistema CQRS más evolucionado podría implementar Event-Sourcing (ES) para la base de datos de actualizaciones, por lo que solo almacenaría eventos en el modelo de dominio en lugar de almacenar los datos de estado actual. Sin embargo, este enfoque no se usa en esta guía. En esta guía se usa el enfoque CQRS más sencillo, que consiste simplemente en separar las consultas de los comandos.

El aspecto de separación de CQRS se logra mediante la agrupación de operaciones de consulta en una capa y comandos de otra capa. Cada capa tiene su propio modelo de datos (tenga en cuenta que decimos modelo, no necesariamente una base de datos diferente) y se crea con su propia combinación de patrones y tecnologías. Lo que es más importante, las dos capas pueden estar dentro del mismo nivel o microservicio, como en el ejemplo (ordenación de microservicios) que se usa para esta guía. O bien, podrían implementarse en diferentes microservicios o procesos para que se puedan optimizar y escalar horizontalmente por separado sin afectar entre sí.

CQRS significa tener dos objetos para una operación de lectura y escritura donde en otros contextos hay uno. Hay razones para tener una base de datos de lecturas desnormalizada, que puede obtener información sobre en la literatura de CQRS más avanzada. Pero no estamos usando ese enfoque aquí, donde el objetivo es tener más flexibilidad en las consultas en lugar de limitar las consultas con restricciones de patrones DDD, como agregados.

Un ejemplo de este tipo de servicio es el microservicio de ordenación de la aplicación de referencia eShopOnContainers. Este servicio implementa un microservicio basado en un enfoque simplificado de CQRS. Usa un único origen de datos o base de datos, pero dos modelos lógicos más patrones DDD para el dominio transaccional, como se muestra en la figura 7-2.

Diagrama que muestra un microservicio CQRS y DDD simplificado de alto nivel.

Figura 7-2. Microservicio simplificado basado en CQRS y DDD

El microservicio lógico "Ordering" incluye su base de datos Ordering, que puede ser, pero no necesariamente tiene que ser, en el mismo servidor Docker. Tener la base de datos en el mismo host de Docker es buena para el desarrollo, pero no para producción.

La capa de aplicación puede ser la propia API web. El aspecto de diseño importante aquí es que el microservicio ha dividido las consultas y ViewModels (modelos de datos especialmente creados para las aplicaciones cliente) de los comandos, el modelo de dominio y las transacciones siguiendo el patrón CQRS. Este enfoque mantiene las consultas independientes de las restricciones y restricciones procedentes de patrones DDD que solo tienen sentido para las transacciones y las actualizaciones, como se explica en secciones posteriores.

Recursos adicionales

Siguiente anterior