No puedes mandar un correo dentro de una transacción de base de datos. Si esa petición de correo tarda, tienes una conexión de base de datos retenida. Eso con un gran volumen de peticiones te deja el pool de conexiones seco. Lo he vivido. Yo no usaría transacciones y le pediría al puerto de base de datos una operación de "rollback" haciendo por ejemplo un borrado lógico del usuario
Pregunto desde mi ignorancia ¿Existe alguna manera de suspender las transacciones para que se retomen posteriormente si sabemos que una operación puede ser costosa?
i think the email its just an example, and it shouldn`t be take literally , i think is more important to discuss the different techniques explained here than the use case. Thanks to @codelly for bringing this great content.
Un error en el envío de un email no debería suspender el registro de un usuario. Para mí son asuntos separados. El usuario se registra, el email va a una cola de envíos y, si falla, se puede reintentar más tarde, pero no podemos tirarle ese "problema" al usuario. Si ya está registrado y guardó su contraseña, va a poder ingresar al sitio. Pregunto: Si tu servidor de email se cae por una hora, tu sitio queda inhabilitado para registrar usuarios?
3 місяці тому+2
Totalmente de acuerdo. El caso de uso termina al registrar usuario en db. El envío de email debería ser una reacción al evento de usuario creado, y dicha reacción esta fuera de la transacción. Si el manejo del evento falla se reintenta al usar colas y asincrónica
3 місяці тому+17
Mal ejemplo. No se debe meter en la misma transacción la creación de un usuario y enviar un email de notificación. La transacción debe acabar al registrar el usuario en db. El envío del email es la reacción al evento de creación de usuario, y eso está fuera de la transacción. 😢
Tienes razón cuál ejemplo tu recomiendas para explicar ese tema?
3 місяці тому+5
@@gabrieltrinidad6397 pues es que esto está directamente relacionado con el diseño de agregados y con ello el diseño de tu sistema. En una transición solo se debe hacer cambios sobre un agregado. El resto son subscripciones al evento que notifica el cambio. La clave es entender conceptos como consistencia eventual y el agregado como frontera transaccional. Es puro DDD
No todos los proyectos necesitan DDD. Tus ejemplos son igual de inútiles que el vídeo. Solamente basta con aplicar el principio de su responsabilidad única para resolver eso.
Mmmm yo no estoy tan seguro de la parte del principio! Hasta donde yo tenía entendido (y hablando con Manu Rivero de Codesai parece que coincide) realmente el paraguas que engloba el resto es la Arquitectura Hexagonal, que simplemente hace distinción entre Infrastructura y "el resto de cosas". Luego, Clean Architecture de Uncle Bob, Onion etc... son implementaciones de esta. Podéis dejar referencias y fuentes de por qué lo habéis justificado así? Gracias!
Al final lo dejais claro: dependiendo de nuestra aplicación, va a ser mejor optar por una solución u otra. En mi caso lo vengo haciendo en los casos de uso (no he necesitado irme a la capa de controladores), con un interfaz específico transaccional, donde realmente no se necesitaría exponer de cierta manera la conexión, si no que es la implementación de ese interfaz transaccional el que tendrá que lidiar con eso. Es más, puede funcionar con sql, no sql, multi base de datos, multi microservicios exerternos, etc, ya que en esta implementación es donde realizas tanto el commit que se necesite como el rollback, que puede ser tan complejo como se necesite para intentar dejar todo como estaba antes del inicio de la primera operación transaccional.
No choca un poco con el separation of concerns que el controlador se ocupe de la transaccionalidad? Se supone que la única responsabilidad del controlador en clean architecture debería ser llamar al caso de uso, nunca trabajar como orquestrador. Si la transaccionalidad la colocas a nivel del controlador, lo estás acoplando a la lógica de negocio No sería más lógico tener un Api Service en la capa de Application que se encargara de orquestrar los diferentes casos de uso y la transaccionalidad y llamarlo directamente desde el controlador? (lo que viene a ser la Anti Corruption layer de DDD)
Las transacciones son mas complejas de lo que en este video se muestra. Incluso hay frameworks y librerías que se encargan de darte una manera de diseñar transacciones por lo que generalmente tendrás que crear un componente parte de infraestructura que maneje y coordine las transacciones.
@@benjaminsepulveda1664 la complejidad de las transacciones no tiene absolutamente nada que ver con la capa en la que las gestionas. Otra cosa es que estemos hablando de transacciones distribuidas o SAGAs, que entonces si que necesitarás un componente externo que trabaje como orquestrador/coreógrafo, pero no es el caso que se trata en el vídeo Por otra parte, que un framework gestione la transaccionalidad no debe afectar para nada a las decisiones de diseño o arquitectura. Spring por ejemplo, gestiona la transaccionalidad vía proxies si se usa la forma declarativa, pero eso no afecta en absolutamente nada a nivel de dónde colocas un @Transactional Además, si lo que necesitas es propagar la transacción, frameworks como Spring te lo permiten Si una librería o framework condiciona tu arquitectura, mala librería/framework
3 місяці тому
@@kzelmer acoplar los casos de uso al controlador/framework está mal. Eso no es Clean Architecture. Los casos de uso a la capa de aplicación y sin dependencias que para eso forman parte del core
En que parte he hablado de acoplar los casos de uso al controlador? He hablado de usar un api service (descrito tanto en los libros de Evans como Vaughn) para trabajar como orquestador de los casos de uso. Quien se acopla al controlador es el api service, no los casos de uso
Si tenéis un command bus como habitualmente sucede en aplicaciones con CQRS, una opción interesante es usar un middleware que realice la transacción y de esta forma no recae la labor en el controller y funcionará igual si es un comando de consola el que ejecuta el caso de uso
@@luisloyola3591 estoy muy contento desde que mejoré la calidad de mi código con la arquitectura de codely, lo único que no me queda 100% claro es como llevar la multiplicidad de base de datos a modelado de dominio
Gran video, pero me queda la duda de que es un mundo ideal en que se tiene la misma base de datos para los dos sistemas. En el caso en que la base de datos legacy sea un MySQL y la del nuevo sistema un mongo por ejemplo?
Cuidado, Los errores no ocurriran entes del commit, yo recommendo llamar a commit antes de mandar el email, en lo contrario si falla la registracion del usuario, nada se grabara en la base de datos, el usuario recibira el mansaje que algo fallo pero a la vez tambien el email de bienvenida, no enrreden las cosas, encapsulen la base de datos a hacer lo que tiene que hacer, y los email en otra encapsulacion, tengo un par de alertas mas, si les gusto esta me lo dicen y escribo otra, no quiero que este video quede como algo malo, la idea de usar transacciones es inmensamente importantisima.
Coincido el ejemplo del email por ahi no fue el mejor, un ejemplo con 2 operaciones sobre la base de datos hubiese sido mas especifico. Sobre todo considerando una operación de enviar un email no es transaccional en si. De todas formas el tema que plantea el video es muy importante y como lo explicaron, de lo que explicaron, me pareció muy bueno.
@@barrenaedu a grandes rasgos, a partir de que inicias una transacción, puedes especificar que partes del código son transaccionales capaces de ir "agregando" más operaciones (o hacer rollback si falla), y así hasta que una operación la configures para hacer commit o decidas hacerlo por tu cuenta, generalmente desde donde la iniciaste.
En caso de usar una base de datos nosql como se debería manejar el "rollback" sobre la BD se debe eliminar manualmente toda la info actualizada? O cuando se vuelva a intentar se debe validar el estado para saber en donde debe continuar.
Se están mezclando responsabilidades, si el registrar usuario fue exitoso no tendría porque hacer un rollback de ese registro si la notificación falla. Es un uso de recurso de la DB innecesaria, mejor ten una forma de reintento o cola de notificaciones fallidas. Vamos chicos, la programación no es una moda por donde encontrar un nuevo espacio en la capa de arquitectura para poner mi lógica. Pero quizá solo dieron un mal ejemplo, no sé.
Hace mucho tiempo que tenía este debate, que buen video para este momento
Son un par de genios explicando, y además le meten mucha pasión..
No puedes mandar un correo dentro de una transacción de base de datos. Si esa petición de correo tarda, tienes una conexión de base de datos retenida. Eso con un gran volumen de peticiones te deja el pool de conexiones seco. Lo he vivido. Yo no usaría transacciones y le pediría al puerto de base de datos una operación de "rollback" haciendo por ejemplo un borrado lógico del usuario
Pregunto desde mi ignorancia ¿Existe alguna manera de suspender las transacciones para que se retomen posteriormente si sabemos que una operación puede ser costosa?
i think the email its just an example, and it shouldn`t be take literally , i think is more important to discuss the different techniques explained here than the use case.
Thanks to @codelly for bringing this great content.
Un error en el envío de un email no debería suspender el registro de un usuario. Para mí son asuntos separados. El usuario se registra, el email va a una cola de envíos y, si falla, se puede reintentar más tarde, pero no podemos tirarle ese "problema" al usuario. Si ya está registrado y guardó su contraseña, va a poder ingresar al sitio. Pregunto: Si tu servidor de email se cae por una hora, tu sitio queda inhabilitado para registrar usuarios?
Totalmente de acuerdo. El caso de uso termina al registrar usuario en db. El envío de email debería ser una reacción al evento de usuario creado, y dicha reacción esta fuera de la transacción. Si el manejo del evento falla se reintenta al usar colas y asincrónica
Mal ejemplo. No se debe meter en la misma transacción la creación de un usuario y enviar un email de notificación. La transacción debe acabar al registrar el usuario en db. El envío del email es la reacción al evento de creación de usuario, y eso está fuera de la transacción. 😢
E J E M P L O
Tienes razón cuál ejemplo tu recomiendas para explicar ese tema?
@@gabrieltrinidad6397 pues es que esto está directamente relacionado con el diseño de agregados y con ello el diseño de tu sistema. En una transición solo se debe hacer cambios sobre un agregado. El resto son subscripciones al evento que notifica el cambio. La clave es entender conceptos como consistencia eventual y el agregado como frontera transaccional. Es puro DDD
Ok ok
No todos los proyectos necesitan DDD. Tus ejemplos son igual de inútiles que el vídeo.
Solamente basta con aplicar el principio de su responsabilidad única para resolver eso.
No se si aplique pero en algún momento vi el patrón Unit of work en este contexto. Ojala puedan abordar el tema en el curso, gracias chicos.
Mmmm yo no estoy tan seguro de la parte del principio! Hasta donde yo tenía entendido (y hablando con Manu Rivero de Codesai parece que coincide) realmente el paraguas que engloba el resto es la Arquitectura Hexagonal, que simplemente hace distinción entre Infrastructura y "el resto de cosas". Luego, Clean Architecture de Uncle Bob, Onion etc... son implementaciones de esta. Podéis dejar referencias y fuentes de por qué lo habéis justificado así? Gracias!
Amo sus videos !
Al final lo dejais claro: dependiendo de nuestra aplicación, va a ser mejor optar por una solución u otra. En mi caso lo vengo haciendo en los casos de uso (no he necesitado irme a la capa de controladores), con un interfaz específico transaccional, donde realmente no se necesitaría exponer de cierta manera la conexión, si no que es la implementación de ese interfaz transaccional el que tendrá que lidiar con eso. Es más, puede funcionar con sql, no sql, multi base de datos, multi microservicios exerternos, etc, ya que en esta implementación es donde realizas tanto el commit que se necesite como el rollback, que puede ser tan complejo como se necesite para intentar dejar todo como estaba antes del inicio de la primera operación transaccional.
Aquí los que les ha dado TOC que diga que es azul cuando es morado 👉🏼
Codely enseña y entretiene
No choca un poco con el separation of concerns que el controlador se ocupe de la transaccionalidad? Se supone que la única responsabilidad del controlador en clean architecture debería ser llamar al caso de uso, nunca trabajar como orquestrador. Si la transaccionalidad la colocas a nivel del controlador, lo estás acoplando a la lógica de negocio
No sería más lógico tener un Api Service en la capa de Application que se encargara de orquestrar los diferentes casos de uso y la transaccionalidad y llamarlo directamente desde el controlador? (lo que viene a ser la Anti Corruption layer de DDD)
Las transacciones son mas complejas de lo que en este video se muestra. Incluso hay frameworks y librerías que se encargan de darte una manera de diseñar transacciones por lo que generalmente tendrás que crear un componente parte de infraestructura que maneje y coordine las transacciones.
@@benjaminsepulveda1664 la complejidad de las transacciones no tiene absolutamente nada que ver con la capa en la que las gestionas. Otra cosa es que estemos hablando de transacciones distribuidas o SAGAs, que entonces si que necesitarás un componente externo que trabaje como orquestrador/coreógrafo, pero no es el caso que se trata en el vídeo
Por otra parte, que un framework gestione la transaccionalidad no debe afectar para nada a las decisiones de diseño o arquitectura. Spring por ejemplo, gestiona la transaccionalidad vía proxies si se usa la forma declarativa, pero eso no afecta en absolutamente nada a nivel de dónde colocas un @Transactional
Además, si lo que necesitas es propagar la transacción, frameworks como Spring te lo permiten
Si una librería o framework condiciona tu arquitectura, mala librería/framework
@@kzelmer acoplar los casos de uso al controlador/framework está mal. Eso no es Clean Architecture. Los casos de uso a la capa de aplicación y sin dependencias que para eso forman parte del core
En que parte he hablado de acoplar los casos de uso al controlador? He hablado de usar un api service (descrito tanto en los libros de Evans como Vaughn) para trabajar como orquestador de los casos de uso. Quien se acopla al controlador es el api service, no los casos de uso
No estan haciendo nada que sea fisica quantica, pero es algo muy complejo para los novatos, por la abstraccion. Enhorabuena porque esta muy claro.
Si tenéis un command bus como habitualmente sucede en aplicaciones con CQRS, una opción interesante es usar un middleware que realice la transacción y de esta forma no recae la labor en el controller y funcionará igual si es un comando de consola el que ejecuta el caso de uso
osea que la clean arquitecture que usa codely en sus repositorios de github, en realidad era la cebolla?
taraaaa asi es xD
@@luisloyola3591 yo incluso empecé a llamarla, arquitectura de codely porque es un poco de cada cosa, toma lo mejor de otras arquitecturas
@@luisloyola3591 estoy muy contento desde que mejoré la calidad de mi código con la arquitectura de codely, lo único que no me queda 100% claro es como llevar la multiplicidad de base de datos a modelado de dominio
Buena explicación
Gran video, pero me queda la duda de que es un mundo ideal en que se tiene la misma base de datos para los dos sistemas. En el caso en que la base de datos legacy sea un MySQL y la del nuevo sistema un mongo por ejemplo?
En ese caso debes utilizar Sagas. Generalmente este patrón se lleva bien con arquitecturas orientada a eventos si hay aplicaciones distribuidas
@@benjaminsepulveda1664 no prefieres el outbox? Menos complicado y no me obliga a compensar estados de sistemas
Cuidado, Los errores no ocurriran entes del commit, yo recommendo llamar a commit antes de mandar el email, en lo contrario si falla la registracion del usuario, nada se grabara en la base de datos, el usuario recibira el mansaje que algo fallo pero a la vez tambien el email de bienvenida, no enrreden las cosas, encapsulen la base de datos a hacer lo que tiene que hacer, y los email en otra encapsulacion, tengo un par de alertas mas, si les gusto esta me lo dicen y escribo otra, no quiero que este video quede como algo malo, la idea de usar transacciones es inmensamente importantisima.
En EF si falla antes del commit cuando se hace el SaveChanges
Coincido el ejemplo del email por ahi no fue el mejor, un ejemplo con 2 operaciones sobre la base de datos hubiese sido mas especifico. Sobre todo considerando una operación de enviar un email no es transaccional en si. De todas formas el tema que plantea el video es muy importante y como lo explicaron, de lo que explicaron, me pareció muy bueno.
¿Qué tal usar propagación de transacciones en las implementaciones concretas?
Como seria esto?
@@barrenaedu a grandes rasgos, a partir de que inicias una transacción, puedes especificar que partes del código son transaccionales capaces de ir "agregando" más operaciones (o hacer rollback si falla), y así hasta que una operación la configures para hacer commit o decidas hacerlo por tu cuenta, generalmente desde donde la iniciaste.
En caso de usar una base de datos nosql como se debería manejar el "rollback" sobre la BD se debe eliminar manualmente toda la info actualizada? O cuando se vuelva a intentar se debe validar el estado para saber en donde debe continuar.
Creo que la primera opción concuerda más con el concepto de "transacción".
Se están mezclando responsabilidades, si el registrar usuario fue exitoso no tendría porque hacer un rollback de ese registro si la notificación falla.
Es un uso de recurso de la DB innecesaria, mejor ten una forma de reintento o cola de notificaciones fallidas.
Vamos chicos, la programación no es una moda por donde encontrar un nuevo espacio en la capa de arquitectura para poner mi lógica.
Pero quizá solo dieron un mal ejemplo, no sé.
tal cual
if user.persisted?
if email_sent?
return
else
user.rollback
end
else
return
end
XD
🤮
goats
Dos cosas totalmente distintas las cuales su funcionamiento no se relaciona directamente con el del otro.
Videos sin sentido.