Servidores de configuración

Sesión 6: 1h30m

Recomendaciones para implementar SAGA

Sesión 5: 4h37m30s

Tenga en cuenta los puntos siguientes al implementar el patrón de saga:

• El patrón de saga inicialmente puede ser desafiante, ya que requiere una neuva forma de pensar sobre cómo coordinar una transacción y mantener la coherencia de los datos para un proceso empresarial que abarque varios microservicios.
• El patrón de saga es especialmente difícil de depurar y la complejidad crece a medida que los participantes aumentan.
• NO SE PUEDEN REVERTIR LOS DATOS porque los participantes de la saga confirman los cambios en sus bases de datos locales.
• La implementación debe ser capaz de controlar un conjunto de posibles errores transitorios y proporcionar idempotencia para reducir los efectos secundarios y garantizar la coherencia de los datos. La idempotencia significa que la misma operación se puede repetir varias veces sin cambiar el resultado inicial.
• Es mejor implementar la observabilidad para supervisar y realizar un seguimiento del flujo de trabajo de la saga.
• La falta de aislamiento de los datos de los participantes impone desafíos de durabilidad. La implementación de la saga debe incluir contramedidas para reducir las anomalías.

Pueden producirse las siguientes anomalías si no se toman las medidas adecuadas:

• Pérdida de actualizaciones, cuando un patrón de saga escribe sin leer los cambios realizados por otro patrón de saga.
• Lecturas de datos sucios, cuando una transación o una saga lee las actualizaciones realizadas por una saga que todavía no ha completado dichas actualizaciones.
• Lecturas aproximadas/no repetibles, cuando diferentes pasos de la saga leen datos diferentes porque se produce una actualización de datos entre las lecturas.

Entre las contramedidas sugeridas para reducir o evitar anomalías se incluyen:

• El bloqueo semántico, un bloqueo de nivel de aplicaicón en el que una transacción de compensable de una saga utiliza un semáforo para indiciar que hay una actualización en curso.
• Las actualizaciones conmutativas que se pueden ejecutar en cualquier orden y generar el mismo resultado.
• Visión pesimista, es posible que una saga lea datos sucios mientras otra saga ejecuta una transacción compensable para revertir la operación. La visión pesimista reordena la saga para que los datos subyacentes se actualicen en una transacción reintentable, lo que elimina la posibilidad de una lectura de datos sucios.
• El valor de relectura comprueba que los datos no se hayan modificado y, a continuación, actualiza el registro. Si el registro ha cambiado, los pasos se anulan y la saga puede reiniciarse.
• Un archivo de versión registra las operaciones en un registro a medida que llegan y las ejecuta en el orden correcto.
• Por valor usa el riesgo empresarial de cada solicitud para seleccionar dinámicamente el mecanismo de simulataneidad. Las solicitudes de bajo riesgo favorecen a las sagas, mientras que las solicitudes de alto riesgo favorencen a las trancciones distribuidas.

Cuando usar SAGA

• Use el patrón de SAGA cuando necesite:
• Garantizar la coherencia de los datos en un sistema distribuido sin acoplamiento estricto.
• Revertir o compensar si se produce un error en una de las operaciones de la secuencia.
• El patrón de saga es menos adecuado para:
• Transacciones estrechamente acopladas
• Transacciones de compensación que se producen en participantes anteriores.
• Dependencias cíciclicas.

Implementación genérica del patrón SAGA a un proceso

Sesión 5: 4h33m

Patrón SAGA

• Reemplaza una transacción distribuida con una saga
• Divide la transacción en muchas solicitudes
• Rastrea cada solicitud
• ACID: compromiso de atomicidad
• Descrito por primera vez en 1987
• También es un patrón de gestión de fallas
• Qué hacer cuando falla un servicio
• Compensar solicitudes
• Implementación: considerar lo siguiente:
• SAGA Log
• Coordinador de ejecución de saga (SEC)
• Solicitudes y compensación de solicitudes

 

Patrón SAGA implementación

• Servicio que inicia la saga
• Envía la solicitud de saga al registro de saga
• Saga Log
• Servicio con una base de datos
• SEC
• Interpreta y escribe en el registro
• Envía solicitudes de saga
• Envía solicitudes de compensación de saga
• Recuperación: estado seguro vs estado inseguro
• Solicitudes de compensación
• Enviar en caso de error para todas las solicitudes completadas
• Idempotente (fácil con REST)
• Cada uno se envía de cero a muchas veces

Patrón SAGA Orchestration

Sesión 5: 4h23m

Nota: Cuando se hagan aplicaciones distribuidas no necesariamente se necestian APIs HTTP, también puede haber Listeners de los microservicios. En tu microservicio puedes tener una parte de exposición y  una parte de listeners. En la nube los listeners se trabajan con workers (Azure Function, Lambda Function). En caso onpremise sería en una consola o servicio windows.

SAGA - Orquestación

Para abordar la complejidad del patrón SAGA, es bastante normal agregar un administador de procesos como administrador. El administrador de procesos es responsable de escuhar eventos y activar puntos finales. Volviendo a la muestra anterior, en lugar de que el servicio de pedido, el servicio de stock y el servicio de envío tengan que escucharse entre sí, implementamos una "gestión de procesos" y estos 3 servicios escucharán esto.

Flujo de SAGA-Orchestration

1. El servicio de pedidos crea un registro de pedido de la base de datos con el estado "Verificando".
2. El servicio de pedidio Solicita al Orquestador iniciar la "Transacción de pedido".
3. El Orquestador envía un "Comando de actualización de stock" al servicio de stock.
4. El servicio de stock actualiza el número del producto solicitado en la base de datos.
5. El servicio de sotck respondeal Orquestador con el mensaje "Stock actualizado correctamente".
6. El Orquestador envía un "Comando de actualización de pedidos" al servicio de pedidos con información de que el stock ya se actualizó correctamente. 
7. Actualización del servicio de pedidos. Registro de pedidos en la base de datos con el estado "Envío".
8. El Orquestador envía un "Comando de envío de registro" al servicio de envío.
9. El servicio de envío inserta un nuevo registro en la base de datos de envíos.
10. El servicio de envío responde al Orquestador con el mensaje "El envío se ha registrado correctamente".
11. El Orquestador envía un "Comando de actualización de pedido" al servicio de pedidos ycon información de que el envío ya se actualizó correctamente.
12. El servicio de pedidos actualiza el registro de pedidos en la base de datos con el estado "Finalizar".

Flujo de Rollback en SAGA-Orchestration (Escenario 1)

Hay un error con el servicio Stock

1. El servicio de pedidos crea un registro de pedido en la base de datos con el estado "Verificando".
2. El servicio de pedido Solicita al Orquestador iniciar la "Transacción de pedido".
3. El Orquestador cenvía un "Comando de actualización de stock.
4. El servicio de stock actualiza el número del producto solicitando en la base de datos. Pero hay un error.
5. El servicio de stock responde con el mensaje "Agotado" al Orquestador.
6. El Orquestador envía un "Comando de orden de reversión" al servicio de pedidos con información de que Stock falló en la actualización.
7. El servicio de pedidos actualiza el regisgtro de pedidos en la base de datos con el estado "Error".

Hay un error con el servicio de envío.

10. El servicio de envío responde con el mensaje "Error al registrar envío" al Orquestador.
11. El Orquestador envía un "Comando de pedido de reversión" al servicio de pedidos con información de que el servicio de envío fallo en el registro.
12. El servicio de pedidos actualiza el registro de pedidos en la base de datos con el estado "Error".
13. El Orquestador envía un "Comando de reversión de stock" al servicio de stock con información de que el servicio de envío falló en el registro.
14. El servicio de stock actualiza el número del peroducto.

Flujo de SAGA-Orchestration

Un formar estándar de modelar una SAGA-Orchestrator es una máquina de estado donde cada transformación corresponde a un comando o mensaje. Las máquinas de estado son un excelente patrón para estructurar un comportamiento bien definido ya que son fáciles de implementar.

Puede utilizar servicios en la nube que pueden ayudarle, por ejemplo:

https://theburningmonk.com/2017/07/applying-the-saga-pattern-with-aws-lambda-and-step-functions/

https://www.freecodecamp.org/news/an-introduction-to-azure-durable-functions-patterns-and-best-practices-b1939ae6c717/

Ventajas y desventajas de SAGA Orchestration

Fácil de mantener todo el flujo de trabajo en un solo lugar. Orquestador. Evita las dependencias cíclicas entre servicios. Todos los servicios solo se comunican con el Orsquestador. La complejidad de la transcción sigue siendo lineal cuando se agregan nuevos pasos.

Sin embargo, para lograr las ventajas anteriores, debe diseñar un orquestador inteligente. Además, tener demasiada lógica en el orquestador podría llevar a difucultades en el mantenimiento.

Patrón SAGA Choreography

Sesión 5: 3h39m

Existen 2 formas de implementar SAGA. 

SAGA - Corografía

La coreografía es una secuencia de pasos o movimientos en la danza... y también es similar en el desarrollo de software si aplicas SAGA - Coreografía. Con este enfoque, cada servicio produce y escucha los eventos de otros servicios, en función del evento de otros servicios decidirá la siguiente acción. La saga utiliza un bus de mensaje para comunicarse.

Flujo de SAGA-Choreography

1. El servicio de pedidos crea un registro en la base de datos con el estado "Verificando".
2. El servicio de pedidos publica un evento "El pedido se ha creado correctamente" y el servicio de Stock escuchará este evento.
3. El servicio de stock actualiza el número de productos de la base de datos stock.
4. El servicio de stock publica un evento "El producto se ha actualizado correctamente" y el servicio de pedidos y el servicio de envío escuchará este evento.
5. El servicio de pedido cambiará el estado del pedidio a "Envío"
6. El servicio de stock publica un evento "El producto se ha actualizado correctamente" y el servicio de pedidos y el servicio de envío escucharán este evento.
7. El servicio de envío crea un registro en la base de datos envíos.
8. El servicio de envío publica un evento "El envío se ha registrado correctamente" y el servicio de pedidos escuchará este evento.
9. El servicio de Pedido cambia el estado del pedido a "Finalizar".

Flujo de Rollback en SAGA-Choreography (Escenario 1)

Hay un error con Stock Service.

1. El servicio de pedidos crea un registro en la base de datos con el estado "Verificando"
2. El servicio de pedidos publica un evento "El pedido se ha creado correctamente" y el servicio de Stock escuchará este evento.
3. El servicio de stock actualiza el número de productos de la base de datos de stock. Pero hay un error inesperado al guardar el registro del producto.
4. Stock Service publica un evento de "reversión" "Error al actualizar el número de productos en stock". 
5. El servicio de pedido cambiará el estado del pedido a "Error".

Flujo de Rollback en SAGA-Choreography (Escenario 2)

El servicio de pedidos y el servicio de stock se ejecutan correctamente. Hay un error con el servicio de envío.

7. El servicio de envío crea un registro en la base de datos de envío. Pero hay un error inesperado al guardar.
8. El servicio de envío publica un evento de "reversión" "Error al registrar el servicio de envío" y tanto el servicio de pedidos.
9. El servicio de envío publica un evento de "reversión" "Error al registrar el servicio de envío" y tanto el servicio de stock.
10. El servicio de pedido cambiará el estado del pedido a "Error".
11. El servicio de stock actualiza el número del producto.

Flujo de SAGA-Choreography

• Tenga en cuenta que es crucial definir un ID compartido común para cada transacción, de modo que cada vez que lance un evento, todos los oyentes puedan saber de inmediato a qué transacción se refiere.
• Las compensaciones también pueden fallar. Pueden haber compensaciones reintentables.

Ventajas y desventajas de SAGA - Coreografía

• La coreografía es la forma más sencilla de implementar el patrón SAGA. Es muy fácil de entender y no requiere demasiado esfuerzo para construir. Cada transacción local en cadena es independiente ya que no tienen conocimiento directo entre sí. Si su transacción distribuida solo incluye de 2 a 4 transacciones locales (servicios), entonces la coreografía es una opción muy adecuada.
• Tener demasiadas transacciones locales hará que el seguimiento de qué servicios escuchan qué eventos, se vuelva complejo. Con la muestra anterior, solo tenemos 3 transacciones locales pero más de 10 pasos para manejar. Imaginemos que cuando tengamos 10 transacciones ¿qué sucederá?

Demo SAGA Choreography

Introducción del patrón SAGA

Sesión 5: 3h21m

Transacciones en un sistema distribuido

• Consistencia de los datos
• Las transacciones son el enfoque tradicional
• Transacciones del sistema monolítico
• Base de datos única, que es la única verdad
• Transacciones de microservicios
• Arquitectura distribuida
• Datos distribuidos
• Transacciones distribuidas
• Teorema de CAP
• La falla de la red sucederá
• Disponibilidad de datos o consistencia de datos

Opciones disponibles a nivel de transaccionalidad

• Transacciones ACID tradicionales
• Atomicidad, consistencia, aislamiento y durabilidad.
• Patrón de confirmación de dos fases (2PC)
• ACID es obligatorio
• Teorema CAP: Elección de consistencia.
• Patrón SAGA
• Atomicidad por disponibilidad y consistencia.
• Para sistemas distribuidos
• Patrón de consistencia eventual
• ACID
• Teorema CAP: Elección de disponibilidad.

Confirmación de 2 fases (Two Phase Commit / 2PC)

Lograr transacciones ACID en sistema distribuido.

• Patrón para transacciones distribuidas
• El administrador de transacciones maneja la transacciones
• Fase de preparación
• El gestor de transacciones notifica el inicio de preparación
• Fase de confirmación
• El gestor de transacciones recibe las confirmaciones.
• Gestor de transacciones
• Emite un Commit en caso todos hayan confirmado.
• Emite un Rollback en caso uno no haya confirmado.

• Advertencias
• Confianza en un administrador de transacciones
• Sin respuesta de confirmación
• Fallar después de una confirmación
• Las transacciones pendientes bloquean recursos
• Evitar implementaciones personalizadas
• Tiene problemas de escalado.
• Rendimiento reducido
• ANTIPATRÓN
• Considerar alternativas
• Patrón de Saga
• Consistencia eventual

Contexto

• Con la adopción del patrón "Base de datos por servicio" en la arquitectura de microservicios, significa que cada servicio tiene su propia base de datos.
• Existe un problema sobre cómo garantizar la coherencia de los datos entre los servicios.
• Por ejemplo, está implementando la función Pedido en un proyecto de Compras en línea. Cuando el usuario final realiza un pedido, la aplicación llamará al servicio de Stock para actualizar el número de producto en el stock, luego llamará al servicio de envío para entregar el producto solicitado al usuario final. 

•   ¿Cuál es el problema?
• ¿Qué sucede si la cantidad del producto es menor que la cantidad que pide el usuario final?
• ¿O qué sucede si hay un problema con el servicio de envío (shipping) y la aplicación no puede registrar el envío correctamente?
• Los pedidos, el artículo y el envío están en diferentes bases de datos, por lo que no podemos usar una transacción ACID local. Esa es la razón por la que no se puede usar uno de los tipos de transacciones que se llama "Confirmación de dos fases" - "2PC".
• Las transacciones distribuidas, como el protocolo de confirmación en dos fases (2PC), requieren que todos los participantes de una transacción la confirmen o reviertan antes de que la transacción pueda continuar. No obstante, algunas implementaciones de participantes, como las bases de datos NoSQL y la administración de mensajes, no admiten este modelo.

SAGA

• El patrón de saga proporciona la administración de transacciones mediante una secuencia de transacciones locales. 
• Una transacción local es el esfuerzo del trabajo atómico realizado por un participante de la saga. 
• Cada transacción local actualiza la base de datos y publica un mensaje o evento para desencadenar la siguiente transacción local en la saga. 
• Si se produce un error en una transacción local, la saga ejecuta una serie de transacciones de compensación que deshacen los cambios realizados por las transacciones locales anteriores.
• No existe el rollback en las transacciones distribuidas gestionadas por saga.
• Saga es la gestión de una transacción para mantener la disponibilidad como la consistencia.

• Las transacciones compensables son transacciones que se pueden invertir procesando otra transacción con el efecto opuesto.
• Una transacción dinámica es el punto en el que se debe continuar o no continuar en una saga. Si se confirma la transacción dinámica, la saga se ejecuta hasta su finalización. Una transacción dinámica puede ser una transacción que no es compensable ni reintentable, o puede ser la última transacción compensable o la primera transacción reintentable de la saga. 
• Las transacciones reintentables son transacciones que siguen a la transacción dinámica y que está garantizando que se realizarán correctamente. 

Implementando CQRS (SQL y NoSQL)

Sesión 5: 2h37m

Ejemplo de implementación de CQRS

 

                     

Consistencia eventual en microservicios

Sesión 5: 1h18m

Requerimientos funcionales de MSA (Microservice Architecture)

Una arquitectura orientada a microservicios tiene que cumplir con algunos requisitos técnicos de arquitectura.

• Débilmente acoplado
• Independientemente cambiable
• Desplegable independientemente
• Contratos de apoyo y honor: El equipo tiene que auto-organizarse.
• API agnóstica a la tecnología
• Diseño para fallos

Cómo diseñar microservicios basados en API

• Estilo arquitectónico: Es el diseño de la aplicación en el nivel más alto de abstracción. Un ejemplo de estilo arquitectónico es microservicios.
• Patrón de arquitectura: cómo van a estar estructurados los componentes. Es una forma de implementar un estilo arquitectónico. Ejemplos:
• Estas capas los voy a organizar con MVC
• Voy a usar el patrón de descomposición DDD
• Voy a utilizar el patrón de BD por servicio
• Uso de Clean Architecture
• Patrón de diseño: Aquí ya estamos viendo código. Casos particulares a nivel de desarollo. Ejemplos:
• Patrón Observer
• Patrón Retry
• Patrón Circuit Breaker

Opciones de arquitectura

• Patrones de arquitectura API
• Facade pattern
• Proxy pattern
• Stateless service pattern
• Estilos de arquitectura API
• Pragmatic REST
• HATEOS (True REST)
• RPC
• SOAP

Estilo de arquitectura REST

Es el estilo arquitectónico que complementa a los microservicios es REST quien permite establecer mecanismos de comunicación.

¿Qué es REST?

• Es un estilo que define restricciones.
• Utiliza una infraestructura basada en HTTP
• Hereda las ventajas de la web
• Conceptos clave
• JSON, XML o CUSTOM
• Endpoints de recursos
• Interfaz de recursos uniforme

Consistencia Eventual

La consistencia eventual es un principio en sistemas distribuidos, como los microservicios, donde no se garantiza la consistencia inmediata de los datos en todo el sistema, pero se asegura que, con el tiempo, todos los nodos (o microservicios) llegarán a un estado consistente.

• Existen sitios web que necesitan un poco de paciencia. Haces una actualización de algo, se actualiza la pantalla y falta la actualización. Esperas uno o dos minutos, pulsas Refresh, y ahi está. 
• Incoherencias como esta son lo suficientemente irritantes, pero pueden ser mucho más graves. La lógica empresarial puede terminar tomando decisiones sobre información inconsistente, cuando esto sucede puede ser extremadamente difícil diagnosticar lo que salió mal porque cualquier investigación se producirá mucho después de que se haya cerrado la ventana de incoherencia.
• Los microservicios introducen problemas de coherencia eventuales debido a su loable insistencia en la administración descentralizada de datos. Con un monolito, puede actualizar un montón de cosas juntas en una sola transacción. 
• Los microservicios requieren varios recursos para actualizar y las transacciones distribuidas se fruncen el ceño (por una buena razón). Por lo tanto, ahora, los desarrolladores deben ser conscientes de los problemas de coherencia y averiguar cómo detectar cuándo las cosas están fuera de sincronización antes de hacer cualquier cosas que el código se arrepentirá. 
• La mayoría de aplicaciones necesitan bloqueos sin conexión para evitar transacciones de base de datos de larga duración.
• Los sistemas externos necesitan actualizaciones que no se puedan coordinar con un administrador de transacciones. 
• Los procesos de negocio son a menudo más tolerantes a las incoherencias, porque las empresas a menudo valoran más la disponibilidad.

Consistencia Eventual - Teorema de CAP

El teorema de CAP nos va a indicar 3 aspectos fundamentales para definir como vamos a modelar nuestra BD o nuestros procesos distribuidos.

• La consistencia (consistency): Cualquier lectura recibe como respuesta la escritura más reciente o un error.
• La disponibilidad (availability): Cualquier petición recibe una respuesta no errónea, pero sin la garantía de que contenga la escritura más reciente.
• Tolerancia al particionado (partition tolerance): El sistema sigue funcionando incluso si un número arbitrario de mensajes son descartados (o retrasados) entre nodos de la red.

Consistencia Eventual

• Los datos eventualmente serán consistentes
• BASE (no va haber una protección de transacción)
• BASE vs ACID
• ACID and BASE are two database transaction models, each with their own advantages and trade-offs. 
• Disponibilidad sobre consistencia
• Evitar el bloqueo de recursos
• Ideal para tareas de larga duración
• Preparado para inconsistencias
• Condiciones de carrera
• Replicación de datos
• Basado en eventos
• Transacción/acciones generadas como eventos
• Mensajes usando message brokers

Demo: Introducción a eventos

1h51m

Bus de Mensajes: Es un gestor de colas. Tenemos tecnologías como Rabbit, Kafka, Azure Service Bus, Amazon SNS, etc. Se recomienda Rabbit para la etapa de desarrollo y utilizar Kafka para producción. 

Nota: Para desarrollo multiplaforma se puede usar Microsoft Orleans.

Patrón CQRS a un microservicio

Sesión 5: 20m30s

El patrón CQRS no es exclusivo de microservicios.

Command Query Responsability Segregation (CQRS)

• CQRS
• Dividir las responsabilidades en lectura y escritura.
• Modelos de comando (Command) y/o servicios
• Modelos de consulta (Query) y/o servicios
• ¿Por qué?
• Separación de responsabilidades
• Notificaciones de eventos manejadas por comando (Escritura)
• Informes/funciones manejadas por consulta (Lectura)
• Separación de tecnologías
• Servicio y almacenamiento
• Desafíos
• Comando y consulta de sincronización de bases de datos.
• Tengo que mantener los datos sincronizados.

Usualmente se usa un Message Broker para actualizar el componente de consulta.

Tipos de CQRS

Ejemplo de código

• Un comando es un DTO
• MediateR es un procesador de comandos
• Usualmente Event Source y CQRS se usan juntos

Patrones de gobierno de datos

Sesión 5: 5m30s

Patrones de estructura de datos

• Base de datos por servicio: Cada microservicio administra sus datos (soberanía de datos). Los desarrolladores usan API's bien definidas para facilitar la comunicación entre las bases de datos de dos o más microservicios.
• Base de datos compartida (antipatrón): Permite que varios servicios accedan y almacenen datos en la misma base de datos. Si usa la base de adtos compartida apra varios microservicios, entonces caerá en un antipatrón y debe evitar estos enfoques.
• Patrón Saga: Saga es una secuencia de transacciones locales en la que el resultado de cada transacción depende de un nuevo evento anterior. Si alguna transacción falla, saga realiza una serie de transacciones de compensación. Gestión de transacciones distribuidas (pseudo transacción por que no cumple con todo los aspectos de una transacción).

No olvidar que los microservicios es una arquitectura lógica. Usualmente va a coincidir con la arquitectura física. Sin embargo, con el tiempo la arquitectura física se va ir complejizando. El uso de los DBLinks en base de datos también es un antipatrón.

Patrones de gestión de comunicación de los datos

• Patrón CQRS: Se proporciona a la base de datos de comandos y consultas separadas para realizar mejor la consulta de varios microservicios. CQRS ofrece un mayor rendimiento y una mejor escalabilidad de los microservicios.
• Patrón Event Sourcing: Proporciona acumular eventos y agregarlos en una secuencia de eventos en bases de datos. De esta manera podemos reproducir a cierto punto de los eventos. Este patrón está muy bien usando con cqrs y patrones de saga.
• Composición de APIs: Utiliza compositores de API para acceder a los conjuntos de datos de los servicios. Después de obtener los datos, el patrón utiliza una "unión en memoria" para emparejar dos servicios antes de enviarlos al consumidor.

Infraestructura de persistencia - NoSQL (CosmosDB)

Sesión 4: 3h48m

Tipos de Base de datos NoSQL

• Clave-Valor: Vincula una clave dada a un registro de cualquier tipo.
• Documental: Se basan en el conceptodetrás de clave-valor, extendiéndolo para admitir objetos complejos de varias capas denominados documentos.
• Columnar: Puede pensar en las filas como claves en un almacén clave-valor y las columnas como el valor.
• Grafos: Enfoque hacia la relación entre entidades. Las entidades, como los usuarios, están representadas por nodos, mientras que las conexiones dictan cómo se relacionan.

¿Cómo elegir la BD más óptima? Teorema CAP

MongoDB

• MongoDB es una base de datos de documentos que ofrece una gran escabilidad y flexibilidad y un modelo de consultas e indexación avanzado.
• MongoDB almacena datos en documentos flexibles similiares a JSON, po lo que los campos pueden variar entre documentos y la estructura de datos puede cambiarse con el tiempo.
• El modelo de documento se asigna a los objetvos en el código de su aplicación para facilitar el trabajo con los datos.
• MongoDB es una base de datos distribuida en su núcleo.

Cosmos DB

• Azure Cosmos DB es un servicio de base de datos con varios modelos distribuidos de forma global de Microsoft. Su compentencia es Amazon Aurora.
• Puede escalar de forma elástica el rendimiento y almacenamiento y sacar provecho del rápido acceso a datos.
• Base de datos relacional: PostgresSQL
• Base de datos NoSQL: MongoDB, Cassandra, Tables o Gremlin.

Infraestructura de persistencia en NET 6 y MS SQL Server 2022

Clase 4: 3h41m

Cuando creamos aplicaciones .NET usualmente utilizamos bases de datos relacional en SQL Server. La herramienta con la que implementamos el acceso a datos es Entity Framework. 

Entity Framework Core

• EF Core es una versión ligera, extensible, de código abierto y multiplataforma de la popular tecnología de acceso a datos Entity Framework.
• EF Core puede servir como asignador relacional de objetos (O/RM), lo que permite a los desarrolladores de .NET trabajar con una base de datos mediante objetos .NET y eliminar la mayoría de acceso a los datos que normalmente deben escribir. 
• EF Core es compatible con muchos motores de bases de datos.

Entity Framework Core - Modelo

• Con EF, el acceso a datos se realiza mediante un modelo.
• Un modelo se compone de clases de entidad y un objeto de contexto que representa una sesión con la base de datos, lo que permite consultar y guardar los datos.
• Puede generar un modelo a partir de una base de datos existente, codificar manualmente un modelo para que coincida con la base de datos o usar migraciones de EF para crear una base de datos a partir del modelo y que evoluciones a mediad que cambia el modelo.

Entity Framework Core - Consultas

• EF Core usa Language Integrated Query (LINQ) para consultar datos de la base de datos. LINQ permite usar C# (o el lenguaje .NET que prefiera) para escribir consultas fuertemente tipadas.
• Usa el contexto derivado y las clases de entidad para hacer referencia a los objetos de base de datos. EF Core pasa una representación de la consulta LINQ al proveedor de la base de datos. A su vez, los proveedores de la base de datos la traducen al lenguaje de la consulta específico para la base de datos (por ejemplo, SQL para una base de datos relacional).

SQL Server / Azure SQL Database

• Una base de datos de SQL Server consta de una colección de tablas en las que se almacena un conjunto específico de datos estructurados.
• Una tabla contiene una colección de filas, tambien denominadas tuplas o registros, y columnas, también denominadas atributos.
• Cada columna de la tabla se ha diseñado para almacenar un determinado tipo de información; por ejemplo, fechas, nombres, importes en monena o números.

Links

• Try examples in your browser
• Entity Framework playground

Gestión de gobierno de datos

Session 4: 3h27m

Gestión descentralizada de datos

Cada microservicio tiene sus propios datos, por lo que la integridad y la coherencia de los datos deben considerarse con mucho cuidado.

El principio fundamental de la gestión de datos de microservicios es que cada microservicio debe administrar sus propios datos, podemos llamar a este principio como una base de datos por servicio. Eso significa que los microservicios no deben compartir bases de datos entre sí. En lugar de eso, cada servicio debe ser responsable de su propia base de datos, a la que otros servicios no pueden acceder directamente.

Debe compartir datos a través de los microservicios de la aplicación con el uso de API REST.

La razón de este aislamiento es romper las dependencias innecesarias entre microservicios. Si hay una actualización en el esqumea de base de datos de un microservicio, la actualización no debe afectar directamente a otros microservicios, incluso otros microservicios no deben conocer los cambios en la base de datos. Al aislar las bases de datos de cada sevicio, podemos limitar el ámbito de los cambios en los microservicios cuando se producen cambios en el esquema de la base de datos.

También de esta manera, podemos elegir diferentes bases de datos según los microservicios, qué base de datos puede elegir la mejor opción. Llamamos a esto principio de "persistencia políglota".

Patrón de base de datos por servicio

¿Un ser vicio puede tener una sola base de datos? Veamos la siguiente sección.

Arquitectura lógica vs Arquitectura física

La creación de microservicios no requiere el uso de ninguna tecnología específica. Por ejemplo, los contenedores de Docker no son obligatorios para crar una arquitectura basada en microservicios. Esos microservicios también se pueden ejecutar como procesos sin formato. Los microservicios son una arquitectura lógica.

La arquitectura lógica y los límites lógicos de un sistema no se asignan necesariamente uno a uno a la arquitectura física o de implementación. Esto puede suceder, pero a menudo no es así.

Por tanto, un microservicio o contexto limitado empresarial es una arquitectura lógica que podría coincidir (o no) con la arquitectura física. Lo importante es que un microservicio o contexto limitado empresarial debe ser autónomo y permitir que el código y el estado ser versionen, implementen y escalen de forma independiente.

Aplicando el patrón Clear Architecture a un microservicio

Session 4: 2h39m

Antecedentes 

En los últimos años hemos visto una amplia gama de ideas con respecto a la arquitectura de los sistemas. Estos incluyen:

• Hexagonal Architecture (a.k.a. Ports and Adapters) por Alistair Cockburn y adoptado por Steve Freeman y Nat Pryce en su libro Growing Object Oriented Software.
• Arquitectura de cebolla por Jeffrey Palermo.
• Screaming Architecture de un blog de Robert C. Martin
• DCI de James Coplien y Trygve Reenskaug.
• BCE por Ivar Jacobson de su libro Object Oriented Software Engineering: A Use-Case Driven Approach.

https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html

Arquitectura Hexagonal

• La arquitectura hexagonal, también conocida como patrón de puertos y adaptadores intentan mantener toda la lógica y los modelos de negocios en un solo lugar y todo los demás depende de esto en lugar de lo contrario.
• Si miramos desde cualquier perspectiva de capas de aplicación, las dependencias serían hacia el dominio desde el controlador/interfaz y la persistencia en lugar de la arquitectura en capas que solemos hacer en nuestros proyectos. De esta manera  hacemos que estos hexágonos sean independientes y puedan relacionarse con el contexto acotado en términos DDD. Al usar la analogía anterior, arquitectura se llamaría "Plugin-Architecture"; Su modelo base permanece intacto y puede ampliar aún más las funcionalidades colocando más implementaciones de plugin que se adhieran a las mismas interfaces.

Objetivo de Clean Architecture

El objetivo principal de Clean Architecture es permitir que el negocio se adapte a la tecnología e interfaces cambiantes. Si bien Internet puede pasar del escritorio al móvil, o del móvil al asistente virtual, el negocio principal sigue siendo el mismo. Particularmente en el acelerado mundo de los marcos de Javascript y las bibliotecas front-end, el uso de una arquitectura limpia puede salvarlo del patrón común de acoplar estrechamente la lógica empresarial a la capa de presentación o al marco.

Características de Clean Architecture

• Se trata de la separación de responsabilidades. Dividir el software en capas.
• Debe ser independiente de los Framworks
• Debe ser testeable
• Debe ser independiente de la interfaz de usuario
• Debe ser independiente de la base de datos
• Debe ser independiente de las dependencias de erd party
• Avanzando hacia adentro, el nivel de abstracción y el aumento de políticas.
• El círculo más interno es el más general/nivel más alto
• Los círculos internos son políticas
• Los círculos exteriores son mecanismos
• Los círculos internos no pueden depender de los círculos externos
• Los círculos exteriores no pueden influir en los círculos internos.

Componentes de Clean Architecture

Entidades

• Las entidades deben ser utilizables por muchas aplicaciones (reglas de negocio críticas) y no deben verse afectadas por nada más que un cambio en la regla de negocio crítica en sí. 
• Encapsulan las reglas más generales/de alto nivel.

Casos de uso

• Los casos de uso son reglas de negocio específicas de la aplicación.
• Los cambios no deben afectar a las Entidades
• Los cambios no deben verse afectados por la infraestructura, como una base de datos.
• Los casos de uso orquestan el flujo de datos que entran/salen de las entidades y dirigen a las entidades a usar sus reglas de negocio críticias para lograr el caso de uso.

Adaptadores de interfaz

• Convierten datos de capas de datos en capas de casos de uso o capas de entidad. Los presentadores, las vistas y los controladores pertenecen aquí.
• Ningún código más avanzado en (casos de uso, entidades) debe tener ningún conocimiento de la base de datos.

Frameworks & Drivers

• Estos son el pegamento que engancha las diversas capas hacia arriba.
• Los detalles de la infraestructura viven aquí.
• No estás escribiendo mucho de código, es decir, usamos SQL Server, perno lo escribimos.

Interacción de Clean Architecture

Cruzando límites

• El flujo de control pasó del controlador, a través del caso de uso de la aplicación, luego al presentador. 
• Las dependencias del código fuente apuntan hacia los casos de uso.
• Principio de inversión de dependencias
• El caso de uso necesita llamar a un presentador, hacerlo violaría la regla de dependencia: los círulos internos no pueden llamar (o conocer) círculos externos.
• El caso de uso necesitaría llamar a una interfaz
• La implementación de esta interfaz sería proporcionada por la capa de adaptador de interfaz: así es como se invierte la dependencia.
• Este mismo tipo de inversión de control se utiliza en toda la arquitectura para invertir el flujo de control.

Datos cruzando fronteras

• Normalmente, los datos que cruzan los límites consisten en estructuras de datos simples.
• No pase objetos de entidad ni filas de datos. Esto violaría las reglas de dependencia.
• Los datos se pasan en el formato que sea más conveniente para el círculo/capa interna.
• Estas son estructuras de datos aisladas y simples.
• Lo que significa que nuestros DTO necesarios para cruzar los límites deben pertenecer al círculo interno, o al menos a su definición (interfaz, clase abstracta).

Ejemplo de código

Links

• Hexagonal Architecture, there are always two sides to every story
• Everything You Need to Know About Hexagonal Architecture: Kernel, Ports, Adapters
• Hexagonal Architecture - What Is It? Why Should You Use It?