Introducción al curso

1

Introducción al curso de Profesional de Arquitectura de Software

Atributos de calidad

2

Definición

3

Atributos: Idoneidad funcional

4

Atributos: Eficiencia de ejecución

5

Atributos: Compatibilidad

6

Atributos: Usabilidad

7

Atributos: Confiabilidad

8

Atributos: Seguridad

9

Atributos: Mantenibilidad

10

Atributos: Portabilidad

11

Tensiones entre atributos

12

Analizando PlatziServicios

Patrones de arquitectura

13

Patrones monolíticos vs distribuidos

14

Patrones: Modelo Vista Controlador

15

Patrones: Capas

16

Patrones: Orientado a eventos / Provisión de eventos.

17

Patrones: Microkernel - Plug-ins

18

Patrones: Comparte-nada

19

Patrones: Microservicios

20

Patrones: CQRS

21

Patrones: Hexagonal - Puertos y adaptadores

22

Patrones: Diseño orientado al dominio

23

Combinando patrones de arquitectura

24

Analizando nuevamente PlatziServicios

Diseño de una arquitectura

25

Pararse en hombros de gigantes

26

Herramientas y partes de un diseño: Tipos de conectores

27

Conectores: Llamado asincrónico / sincrónico. Modelo Cliente servidor.

28

Conectores: Enrutador, difusión

29

Conectores: Pizarra, repositorio, colas, modelo PUBSUB

30

Escenarios y tácticas

31

Escenarios: Disponibilidad, detección, reparación

32

Escenarios: Reintroducción y prevención

33

Escenarios: Mantenibilidad

34

Escenarios: Prevenir efectos dominó y diferir enlace

35

Escenarios: Eficiencia de ejecución

36

Escenarios: Seguridad

37

Escenarios: Capacidad de prueba

38

Escenarios: Usabilidad

39

Validar las decisiones de diseño: Arquitectura en evolución

40

Último análisis a PlatziServicios

Modelado y documentación de arquitectura

41

Cómo comunicar la arquitectura: Vistas y Puntos de vista

42

Documentación vs implementación

43

Conclusiones del curso

No tienes acceso a esta clase

¡Continúa aprendiendo! Únete y comienza a potenciar tu carrera

Patrones: CQRS

20/43
Recursos

Aportes 15

Preguntas 2

Ordenar por:

¿Quieres ver más aportes, preguntas y respuestas de la comunidad?

Como ejemplo, para una aplicación que desarrollamos en mi empresa utilizamos el modelo CQRS de la siguiente manera:

  • La aplicación móvil interaccionaba con un respositorio NoSQL (AWS: DynamoDB) para priorizar los tiempos de respuesta, especialmente de escritura.

  • Utilizamos una arquitectura basada en eventos para replicar los datos en tiempo real a una BD en MySQL optimizado para la reportería.

Con lo anterior ganamos en:

  • Aseguramos una alta disponbilidad y rápidos tiempos de respuesta para la aplicación móvil.
  • Aseguramos excelentes tiempos de respuesta para la reportería.

Pero perdimos en:

  • Complejidad de instalación.
  • Complejidad de testing, que llegó a ser bastante complejo.
  • Integridad de la información, ya que se vuelve muy complejo asegurar que la data es íntegra en ambos repositorios.

Apuntes:

CQRS: Separación de Responsabilidades entre Consultas y Comandos

Nos dice que cuándo es muy difícil hacer óptima la lectura y escritura con un modelo compartido podemos aprovechar eso para separar ese modelo e incluso separar las bases de datos de esos modelos, de esta manera cuando queremos escribir tenemos un modelo optimizado para la escritura y luego cuando queremos leer tenemos un modelo optimizado para la lectura. Nos sirve para poder modelar el dominio de escritura y a su vez tener preparados los datos para poder leerlos de la mejor forma posible.

Command Query Responsability Segregation (CQRS), es un estilo arquitectónico en el que tenemos dos subsistemas diferenciados, uno responsable de los comandos, y otro responsable de las consultas. Por comando entendemos un petición por parte del usuario u otro sistema, para realizar una operación de negocio, que evolucione el sistema de un estado a otro. Cada uno de estos subsistemas tiene un diseño, modelo de información y mecanismo de persistencia diferente, optimizado para las tareas que deba afrontar. Normalmente el subsistema de consulta suele ser mucho más simple que el otro.

Les dejo aquí este artículo que explica muy bien este patrón de diseño https://eamodeorubio.wordpress.com/2012/09/03/cqrs-1-que-es/

Patrones: Separación de Rsponsabilidades entre Consultas y Comandos / CQRS

Diferencia el momento del que estamos escribiendo del de que estamos leyendo. Nos permite modelar el dominio de a escritura y a su vez tener preparados ya sus datos para poder leerlos de la mejor forma posible. Caso de uso: reportes.


Este es un patron puntual, puede generar sobre-costos.

me mate buscando informacion sobre esto en la web jajaja, pensar que estaba aqui y tan bien explicado

CQRS: Se utilizan mas en reportes y eventos.
CQRS( Separación de responsabilidades entre consultas y comandos).

Patron de arquitectura Separacion de Responsabilidades entre Consultas y Comandos o CQRS
Sirve para diferenciar el momento en el que estamos escribiendo del momento en el que leemos.
Modelos optimizados para lectura y escritura.

En mí caso he utilizado mucho este patrón para temas de BI. Por ejemplo, por un lado, se tiene el sistema transaccional de las aplicaciones, por otro lado, se tiene los datos de reportería.
.
Normalmente el llenado de tablas para reportes se realiza en la madruga donde no hay tanto uso del sistema transaccional, así poder hacer la extracción para tener la información en las bases para los reportes; De esta manera se asegura que pueda ser consultado por el usuario sin afectar el sistema transaccional al momento de hacer operaciones de escritura.

¿La tecnología BlockChain tiene algo que ver con este patrón?

No soy ningún experto con CQRS, pero no necesariamente se ocupa solo para eso de tener 2 BD separadas, a veces es para tener el codigo más limpio, es decir, por un lado tener comandos y por el otro lectura, así el código está mejor estructurado, especialmente cuando se ocupa en conjunto con el patrón mediador.

Estos 2 patrones Mediador y CQRS se ocupan muy comunmente en aplicaciones grandes.

Command Query Responsibility Segregation = separación de responsabilidades entre consultas y comandos (CQRS)

🤖🤖🤖
CQRS:
La segregación de responsabilidades de consultas y comandos (CQRS), Es un estilo de arquitectura que separa las operaciones de lectura de las operaciones de escritura.
Los comandos, Deberían basarse en tareas, en lugar de centrarse en datos. (“Reservar habitación de hotel” y no “Establecer ReservationStatus en Reservado”). Los comandos se pueden colocar en una cola para un procesamiento asincrónico, en lugar de que se procesen de forma sincrónica.
Las consultas, Nunca modifican la base de datos. Una consulta devuelve un DTO que no encapsula ningún conocimiento del dominio.

Ejemplo de la estructura de directorios para un proyecto de generación de reportes utilizando el patrón CQRS (Command Query Responsibility Segregation). En este patrón, separamos la parte que se encarga de los comandos (escritura) de la parte que maneja las consultas (lectura). Esto permite una mayor optimización, escalabilidad y flexibilidad, especialmente en proyectos como la generación de reportes, donde la consulta de datos es frecuente. /reporting-system │ ├── /command-side # Lado de comandos (Escritura) │ ├── /src │ │ ├── /domain # Lógica de negocio para la escritura │ │ │ ├── /aggregates # Agregados del dominio │ │ │ ├── /entities # Entidades del dominio │ │ │ ├── /repositories # Interfaces de repositorios │ │ │ └── /services # Servicios del dominio (escritura) │ │ ├── /application # Capa de aplicación para comandos │ │ │ ├── /commands # Comandos del sistema │ │ │ └── /handlers # Manejadores de comandos │ │ ├── /infrastructure # Capa de infraestructura │ │ │ ├── /event-store # Almacenamiento de eventos │ │ │ ├── /persistence # Implementaciones de repositorios │ │ │ ├── /migrations # Migraciones de base de datos │ │ │ └── /services # Servicios externos (colas, bases de datos, etc.) │ │ └── /config # Archivos de configuración │ ├── /tests # Pruebas unitarias y de integración │ ├── Dockerfile # Configuración para Docker │ ├── package.json # Dependencias del servicio de comandos │ └── README.md # Documentación del lado de comandos │ ├── /query-side # Lado de consultas (Lectura) │ ├── /src │ │ ├── /domain # Lógica de negocio para la lectura │ │ │ ├── /entities # Entidades del dominio de lectura │ │ │ └── /repositories # Repositorios de lectura │ │ ├── /application # Capa de aplicación para consultas │ │ │ ├── /queries # Consultas del sistema │ │ │ └── /handlers # Manejadores de consultas │ │ ├── /infrastructure # Capa de infraestructura │ │ │ ├── /read-database # Bases de datos de lectura │ │ │ ├── /caching # Servicios de caché para optimización de lecturas │ │ │ └── /services # Servicios externos (colas, bases de datos, etc.) │ │ └── /config # Archivos de configuración │ ├── /tests # Pruebas unitarias y de integración │ ├── Dockerfile # Configuración para Docker │ ├── package.json # Dependencias del servicio de consultas │ └── README.md # Documentación del lado de consultas │ ├── /event-bus # Bus de eventos para comunicación entre lados │ ├── /src │ │ └── /subscribers # Subscriptores a eventos del sistema │ ├── /tests # Pruebas del bus de eventos │ ├── Dockerfile │ ├── package.json │ └── README.md │ ├── /common # Código compartido entre el lado de comandos y consultas │ ├── /exceptions # Excepciones comunes │ ├── /utils # Utilidades compartidas │ ├── /events # Eventos compartidos entre comandos y consultas │ └── README.md │ ├── /api-gateway # API Gateway que maneja peticiones HTTP │ ├── /src │ │ ├── /routes # Definición de rutas para comandos y consultas │ │ └── /controllers # Controladores que manejan las rutas │ ├── /tests # Pruebas del API Gateway │ ├── Dockerfile │ ├── package.json │ └── README.md │ ├── /kubernetes # Archivos de configuración para Kubernetes │ ├── /command-side.yaml # Configuración de despliegue para el lado de comandos │ ├── /query-side.yaml # Configuración de despliegue para el lado de consultas │ ├── /event-bus.yaml # Configuración de despliegue para el bus de eventos │ └── /api-gateway.yaml # Configuración de despliegue para el API Gateway │ ├── /docker-compose.yml # Configuración de Docker Compose para desarrollo local ├── /README.md # Documentación general del proyecto └── /package.json # Dependencias generales del proyecto (si las hay) ### Explicación de la Estructura 1. **Command-Side (Escritura)**: * Este lado se encarga de las operaciones que modifican el estado del sistema, como crear, actualizar o eliminar reportes. * Contiene: * **Domain**: Agregados, entidades, y lógica de negocio relacionada con la escritura. * **Application**: Comandos (como "Generar Reporte") y sus manejadores, que aplican cambios al sistema. * **Infrastructure**: Implementaciones de repositorios, almacenamiento de eventos, y servicios externos. 2. **Query-Side (Lectura)**: * Este lado se encarga de las operaciones que solo consultan datos sin modificar el estado, como obtener reportes o ver detalles. * Contiene: * **Domain**: Entidades y lógica de negocio relacionada con la lectura. * **Application**: Consultas (como "Obtener Reporte por Fecha") y sus manejadores. * **Infrastructure**: Bases de datos optimizadas para lectura y mecanismos de caché. 3. **Event-Bus**: * El **bus de eventos** maneja la comunicación entre los lados de comandos y consultas. Cada vez que se produce un cambio en el lado de comandos, se publica un evento que actualiza el lado de consultas (ej. "ReporteCreado"). 4. **API Gateway**: * El **API Gateway** es la puerta de entrada para las solicitudes HTTP. Maneja la redirección de comandos (escrituras) hacia el lado de comandos y de consultas (lecturas) hacia el lado de consultas. 5. **Common**: * Contiene código compartido entre ambos lados, como excepciones, utilidades, y eventos comunes. 6. **Kubernetes**: * Archivos de configuración para el despliegue en un entorno de orquestación como Kubernetes. 7. **Docker Compose**: * Configuración para ejecutar los servicios de manera local utilizando contenedores Docker. ### Ventajas de CQRS en Reportes * **Escalabilidad**: Puedes escalar independientemente el lado de escritura y el lado de lectura según las necesidades del sistema. * **Optimización**: Permite optimizar las consultas de lectura con bases de datos especializadas sin afectar la escritura. * **Separación de responsabilidades**: Facilita la gestión de la complejidad al dividir claramente las tareas de comando y consulta.
Ejemplo: Sistema de Pedidos e Inventario en Comercio Electrónico Comandos (Commands): Las operaciones de escritura, como crear un pedido, actualizar el inventario o procesar devoluciones, se manejan en un modelo separado. Cada vez que un cliente realiza un pedido, el comando reduce el inventario correspondiente. Consultas (Queries): Las operaciones de lectura se manejan en un modelo separado que permite obtener rápidamente el inventario disponible o el historial de pedidos del usuario. Esto asegura que el sistema puede responder rápidamente a las solicitudes de los usuarios sin esperar que se completen las operaciones de escritura. Beneficio: Al separar las responsabilidades de lectura y escritura, CQRS permite escalar y optimizar cada modelo independientemente. Esto es especialmente útil para aplicaciones de alto tráfico, donde las operaciones de consulta son frecuentes y deben ser rápidas, mientras que las actualizaciones de datos pueden ocurrir en un proceso paralelo.