Capítulo 4: Construcción de Mensajes¶
Introducción¶
Los capítulos anteriores establecieron por dónde viajan los mensajes (canales) y qué son los mensajes (estructura de headers y body). Este capítulo aborda una pregunta igualmente fundamental: ¿qué semántica tiene un mensaje? Es decir, ¿qué significa el mensaje para el productor y el consumidor, y cómo se construye para que esa semántica sea clara, procesable y evolucionable?
La construcción de un mensaje no es un acto trivial de serializar datos. Involucra decisiones de diseño que determinan:
- La intención del mensaje: ¿es una instrucción para que alguien haga algo? ¿Es una notificación de algo que ya ocurrió? ¿Es un documento con datos para consulta?
- El patrón de interacción: ¿el productor espera una respuesta? ¿Cómo se correlacionan mensajes relacionados? ¿Cómo se indentifica el destino de retorno?
- La gestión temporal: ¿el mensaje tiene fecha de expiración? ¿Forma parte de una secuencia ordenada?
- La evolución del formato: ¿cómo sabe el consumidor qué versión del formato está recibiendo?
Estas decisiones son el contrato semántico del messaging. Tomarlas explícitamente y con criterio es lo que distingue una arquitectura de integración profesional de una colección de sistemas que se envían bytes.
Los Nueve Patrones de Construcción¶
| Patrón | Pregunta que responde | Semántica |
|---|---|---|
| Command Message | ¿Cómo se envía una instrucción a un sistema remoto? | Imperativa |
| Document Message | ¿Cómo se envían datos para que el receptor los use como necesite? | Informativa |
| Event Message | ¿Cómo se notifica que algo ocurrió? | Notificación |
| Request-Reply | ¿Cómo se obtiene una respuesta a través de messaging? | Bidireccional |
| Return Address | ¿Cómo sabe el receptor dónde enviar la respuesta? | Direccionamiento |
| Correlation Identifier | ¿Cómo se vincula una respuesta con su petición original? | Correlación |
| Message Sequence | ¿Cómo se manejan datos que no caben en un solo mensaje? | Fragmentación |
| Message Expiration | ¿Cómo se evita procesar mensajes obsoletos? | Temporalidad |
| Format Indicator | ¿Cómo sabe el receptor qué formato tiene el mensaje? | Versionado |
La Trinidad Fundamental: Command, Document, Event¶
Los tres primeros patrones de este capítulo — Command Message, Document Message y Event Message — forman una clasificación tripartita de la semántica de los mensajes que es absolutamente central en las arquitecturas modernas:
- Command: "Haz esto" → El productor instruye al consumidor a ejecutar una acción específica. Implica que el productor sabe qué debe hacer el consumidor.
- Document: "Aquí están los datos" → El productor envía datos al consumidor sin prescribir qué hacer con ellos. El consumidor decide.
- Event: "Esto ocurrió" → El productor notifica que un hecho relevante tuvo lugar. No instruye ni prescribe — simplemente informa.
Esta clasificación mapea directamente a los conceptos modernos de:
- Commands → CQRS command side, API calls imperativas, task queues
- Documents → Data transfer objects, bulk data, query responses
- Events → Domain events, integration events, change notifications, event sourcing
Comprender cuándo usar cada tipo y las consecuencias de cada elección es una de las decisiones de diseño más impactantes en una arquitectura event-driven.
Patrones de Interacción: Request-Reply, Return Address, Correlation Identifier¶
Los patrones 4, 5 y 6 trabajan juntos para resolver uno de los problemas más complejos del messaging asíncrono: la comunicación bidireccional. En una llamada síncrona (REST, gRPC), la respuesta llega por el mismo canal que la petición. En messaging, la respuesta viaja por un canal diferente y puede llegar en un momento diferente. Request-Reply define el patrón general, Return Address resuelve el enrutamiento de la respuesta y Correlation Identifier resuelve la vinculación entre petición y respuesta.
Patrones de Gestión: Sequence, Expiration, Format¶
Los patrones 7, 8 y 9 abordan problemas prácticos de la construcción de mensajes:
- Message Sequence: cuando los datos son demasiado grandes para un solo mensaje, se fragmentan en una secuencia que debe reconstruirse.
- Message Expiration: cuando un mensaje tiene un tiempo de vida limitado y procesarlo después de ese tiempo es incorrecto o inútil.
- Format Indicator: cuando productores y consumidores pueden estar usando diferentes versiones del formato del mensaje y necesitan un mecanismo de detección.
Mapa del Capítulo¶
| Patrón | Función | Vigencia |
|---|---|---|
| Command Message | Instrucción de ejecución | Alta |
| Document Message | Transferencia de datos | Alta |
| Event Message | Notificación de hechos | Alta |
| Request-Reply | Interacción bidireccional asíncrona | Alta |
| Return Address | Direccionamiento de respuestas | Alta |
| Correlation Identifier | Vinculación de mensajes relacionados | Alta |
| Message Sequence | Fragmentación de mensajes grandes | Media |
| Message Expiration | TTL y obsolescencia de mensajes | Alta |
| Format Indicator | Detección de versión de formato | Alta |
A continuación, cada patrón de construcción se analiza en profundidad.