Saltar al contenido
Framework Ecosystems LabsUn contrato, muchos ecosistemas, la misma prueba.

Por qué sí y por qué no — Eventos de dominio#

⬅️ Clase 113 · 📚 Parte 8

Por qué sí Por qué no Qué se paga
Express Quince líneas y el bus entero se lee de un vistazo Nada del framework: la protección del emisor la pones tú Acordarse del try dentro del bucle
FastAPI Lo mismo, y un diccionario de listas es idiomático Lo mismo Lo mismo
Spring Boot Lo trae de serie, y los consumidores se descubren solos Síncrono, en la transacción, y una excepción rompe la petición Conocer dos trampas que nadie espera
ASP.NET Core El contenedor lo hace natural, con dependencias por consumidor Hay que registrarlo en el arranque, no basta con escribirlo Un sitio más donde acordarse de dar de alta cosas

🧭 Lo que este contrato no puede probar#

💡 Lo que hay que llevarse#

Lo primero es que un bus de eventos no es infraestructura. Son quince líneas en tres de los cuatro frameworks, y cero en Spring. Lo que cambia no es la tecnología: es la dirección de las llamadas. El alta deja de llamar al correo y pasa a anunciar lo que pasó; quien tenga algo que hacer con eso, que se apunte. Y a partir de ahí, añadir la quinta reacción no toca el alta.

Lo segundo es la línea que decide si esto vale: el try dentro del bucle de publicar. Sin él, el primer consumidor que reviente deja sin ejecutar a los siguientes y devuelve el error a quien publicó —es decir, rompe un alta que ya estaba hecha por culpa de un correo—. Es exactamente el problema que el desacoplamiento venía a resolver, reaparecido por la puerta de atrás.

Lo tercero son las dos trampas de Spring, que son la contrapartida de traerlo de serie: es síncrono y dentro de la misma transacción, y una excepción del consumidor sube hasta quien publicó. Las dos pueden ser lo que quieres —que el correo no salga si la transacción se deshace es una buena propiedad— y ninguna es lo que la gente espera por defecto de algo que se llama bus de eventos.

Y lo cuarto, el agujero que las cuatro dejan y las cuatro declaran: el fallo se pierde. Capturar y seguir es lo mínimo correcto y no es suficiente. Para que un consumidor que falla se pueda reintentar, el evento tiene que estar guardado antes de publicarse —en la misma transacción que el alta, idealmente— y alguien tiene que releerlo después. Ese patrón tiene nombre y es la pieza que convierte esta clase en algo de producción; combinarlo con la idempotencia de la clase 112 es lo que hace que reintentar no duplique.

Fuentes#