Ddd

Los cuatro artículos anteriores de la serie pusieron las bases para que un sistema distribuido se mantenga coherente: Saga para orquestar workflows, Outbox para publicar eventos fiables, Inbox para consumirlos sin duplicados, Idempotency Keys para proteger la API. Queda una pregunta: ¿qué se hace con los eventos una vez publicados? La respuesta más frecuente es: se usan para construir vistas de lectura. Es exactamente lo que propone el patrón CQRS (Command Query Responsibility Segregation): separar el modelo de escritura del modelo de lectura, cuando ambos divergen lo suficiente como para que forzarlos en una misma estructura cueste más que duplicarlos. ...

El artículo anterior sobre el Transactional Outbox estableció una garantía clara: todo evento escrito en base acabará siendo publicado. Esa garantía es intencionadamente at-least-once. Un consumidor puede recibir el mismo evento dos veces, tres veces, o más si la red se porta mal. El patrón Outbox nunca promete unicidad. La consecuencia es inmediata: si el consumidor aplica dos veces el efecto del mensaje, factura dos veces, envía dos correos, descuenta stock dos veces. La coherencia garantizada del lado productor se rompe del lado lector. ...

Cuando un servicio modifica su base y quiere avisar al resto del sistema enviando un evento a Kafka, RabbitMQ o SQS, el código ingenuo se parece a esto: escribir en base y luego publicar. Si la publicación falla tras el commit, el evento se pierde. Si la publicación tiene éxito pero el commit falla, el evento habla de un estado que no existe. Ambos casos son la definición del dual-write problem. ...

Una operación de negocio que toca varios servicios plantea una pregunta que SQL resuelve desde hace cincuenta años dentro de una sola base de datos: ¿qué pasa cuando un paso tiene éxito y el siguiente falla? Mientras todo vive en la misma base, BEGIN ... ROLLBACK basta. En cuanto llamas a un servicio externo, una API de terceros u otra base de datos, esa red de seguridad desaparece. El patrón Saga responde a esa pregunta. En lugar de intentar una transacción ACID imposible, divide la operación en pasos locales, cada uno acompañado de una transacción compensatoria que sabe deshacer su efecto. Si el paso 4 falla, las compensaciones de los pasos 1, 2 y 3 se reproducen en orden inverso. ...

Consumir una API externa parece inofensivo al principio. Haces un requests.get, recibes un diccionario, y lo usas tal cual en el resto del código. El problema empieza cuando esa misma estructura JSON termina diseminada en diez archivos, y la API renombra un campo o cambia price de float a string. Corregirlo se convierte en una búsqueda del tesoro. La capa anti-corrupción (Anti-Corruption Layer, o ACL) responde a este problema. Procedente del Domain-Driven Design, actúa como un traductor entre un sistema externo y tu lógica de negocio. Un solo punto de contacto, un solo lugar que modificar cuando la API cambia. ...

Este blog es ante todo un espacio de intercambio: descubrimientos, reflexiones, cosas que me han sido útiles y que podrían serlo para otros. Python, Django, Arquitectura y buenas prácticas: el núcleo del blog El núcleo del blog es el desarrollo en Python, y más concretamente los frameworks que estructuran mi día a día: Django, FastAPI y Flask. Cada uno tiene sus puntos fuertes, sus casos de uso, sus trampas. Profundizaremos en todos ellos. ...