Communication

Pregunta e intención

Communication responde cómo intercambian información, requests, resultados o señales las unidades arquitectónicas. Examina canales, dirección, forma de interacción y condiciones bajo las cuales un intercambio tiene significado útil. Elegir HTTP o un broker resuelve una parte, no toda la decisión.

decomposition define responsabilidades y fronteras. dependency-structure identifica conocimiento y capacidades de los que dependen. Communication observa su colaboración efectiva. Una división en Orders, Payments, Inventory y Shipping admite varias formas de intercambio sin que las alternativas resulten arquitectónicamente equivalentes.

El eje debe permanecer technology-neutral: los mecanismos cambian, pero siguen importando espera, disponibilidad, interpretación, estado, fallos y obligaciones. connectors representa mecanismos o relaciones de interacción en una vista concreta; Communication aporta las preguntas para comparar sus condiciones, sin ser sinónimo de connector. No es un catálogo de protocolos ni una afirmación de que todos los intercambios deban usar mensajes.

Dimensiones que se combinan

Estas preguntas no describen pares mutuamente excluyentes para toda arquitectura:

Dimensión	Qué conviene precisar
Local / remote	¿La interacción cruza un proceso, nodo o red y qué frontera concreta observamos?
Synchronous / asynchronous	¿Qué continuación necesita esperar y qué resultado habilita progreso?
Request/response / one-way	¿Existe una respuesta correlacionada o solamente un envío en este intercambio?
Direct / mediated	¿Los participantes se conectan directamente o interviene un intermediario?
Call-based / message-event-based	¿Se invoca una operación o se transmite una representación para interpretar?
Stateful / stateless interaction	¿Qué contexto debe conservarse entre intercambios y quién lo mantiene?

Un sistema puede usar llamadas locales, API remota síncrona y publicación de eventos para operaciones diferentes. La misma integración puede aceptar solicitudes, responder acuses y emitir resultados posteriores. La descripción necesita separar esos momentos.

Remote no significa asynchronous. Un mensaje tampoco demuestra Event-Driven Architecture. El nombre de una tecnología no determina espera ni dependencia temporal del negocio.

Interacción local

Orders puede invocar un contrato local de Payments dentro del mismo proceso. La implementación recibe valores mediante mecanismos del lenguaje y puede devolver un resultado directamente. Hay que decidir acceso a objetos, mutabilidad, errores y concurrencia; la proximidad no sustituye contratos.

Local no garantiza operación atómica, ausencia de fallos ni respuesta inmediata. El colaborador puede usar I/O, competir por locks o realizar efectos antes de fallar. Un objeto compartido puede permitir cambios de estado que una frontera pretendía impedir.

Una queue interna o callback permite otra interacción local. Puede separar ejecución y agregar buffering, mientras comparte proceso y recursos. No obtiene automáticamente durabilidad ni aislamiento de fallos: perder el proceso puede perder trabajo pendiente si no existe otra protección.

Comunicación remota

Waldo y sus coautores explican que la distribución introduce diferencias sustanciales de latencia, acceso a memoria, concurrencia y fallos parciales. No basta con esconderlas bajo una interfaz similar a la local. A Note on Distributed Computing, 1994.

La red incorpora serialización, disponibilidad de enlaces, límites de seguridad y compatibilidad entre participantes que pueden cambiar por separado. La representación transferida no es el mismo objeto compartido en memoria. Autenticación y autorización deben corresponder a esa frontera, sin desarrollarse aquí como procedimientos de seguridad.

Orders puede recibir un timeout mientras Payments ya autorizó el pago. La ausencia de respuesta no demuestra ausencia de efecto. timeout, retry y circuit-breaker permiten continuar hacia límites de espera, repetición y admisión sin copiar sus políticas. Una llamada remota no equivale a una llamada local con sintaxis más lenta.

Synchronous y asynchronous: declarar qué espera

Una interacción síncrona requiere normalmente un resultado o acknowledgment para continuar cierto flujo. En una asíncrona, quien envía puede avanzar sin que el receptor complete inmediatamente el trabajo. Esa descripción necesita señalar la frontera de continuación que importa.

Un HTTP client puede usar una API no bloqueante y liberar el thread mientras Orders sigue esperando autorización para confirmar el pedido. Execution no bloqueante no elimina una dependencia temporal del workflow. Una future puede representar trabajo pendiente, no un resultado de negocio ya obtenido.

Asynchronous no implica broker. Puede utilizar tareas, callbacks, streams, queues internas o mensajería durable. Tampoco significa que nunca se espere: un productor puede esperar aceptación del envío y luego observar finalización mediante otro intercambio.

El acuse de transporte, la persistencia del mensaje y la finalización de negocio son garantías diferentes. Explicar qué confirma cada señal evita llamar exitoso a un pago únicamente porque se aceptó su solicitud.

Request/response y mensajes

Request/response permite pedir una operación y obtener un resultado relacionado. Puede facilitar feedback y razonamiento sobre un recorrido, y conectar tiempos y disponibilidad de participantes. No es una opción incorrecta por definición.

Enterprise Integration Patterns muestra que Request-Reply sobre mensajería admite variantes de espera y continuación. El transporte por mensajes no decide por sí solo si el solicitante bloquea o procesa la respuesta después. Request-Reply.

En Commerce, Orders puede enviar AuthorizePayment y correlacionar una respuesta con pedido e intento. Esperar esa respuesta mantiene una necesidad de resultado aunque el canal tenga buffering. Un acuse de recepción no sustituye la respuesta que autoriza seguir.

One-way, buffering y resultados posteriores

Un envío one-way no espera una respuesta dentro de ese intercambio. Puede participar en una conversación mayor que sí requiere resultados posteriores. La forma local de enviar no define por sí sola las obligaciones de todo el flujo.

Mensajería puede permitir procesamiento independiente y desacoplar disponibilidad instantánea cuando el canal conserva trabajo. Agrega decisiones sobre entrega, duplicados, orden, backlog y diagnóstico. reliable-messaging, at-least-once, idempotency y dead-letter-queue desarrollan esas obligaciones.

Si Shipping recibe OrderReadyForShipping, debe acordarse qué confirma recepción y qué informa envío efectivo. Una queue con trabajo acumulado no demuestra capacidad suficiente ni aislamiento completo. Hay que observar edad de mensajes y resultado requerido, no solo que el productor dejó de esperar.

Commands, eventos y semántica

Una solicitud pide una acción; una notificación de evento comunica un hecho relevante según su contrato. EIP describe cómo transportar notificaciones mediante Event Message. El papel se reconoce por obligaciones y significado, no solamente por un sufijo del nombre.

PaymentAuthorized puede anunciar un resultado que Payments ya considera válido. Orders necesita interpretar moneda, importe, identidad y condiciones de reversión relevantes. Una publicación sin consumidor directo en el código todavía tiene un contrato.

event-driven-architecture examina cuándo los hechos y sus reacciones adquieren significancia arquitectónica. Usar algunos eventos no caracteriza automáticamente todo el sistema como EDA; solicitudes, consultas y decisiones locales pueden coexistir. El profile distingue semántica de eventos de una elección de canal aislada.

Dirección, intermediación y contexto

Una interacción puede ser one-to-one, one-to-many o many-to-one. Un intermediario puede enrutar, conservar o transformar información. Esas posibilidades añaden disponibilidad, contratos y capacidad operacional que el análisis debe incluir; no constituyen un catálogo de topologías universal.

Stateful interaction conserva contexto entre intercambios, como sesión o conversación. Stateless interaction exige información suficiente para tratar cada solicitud según el contrato, sin depender de una sesión conversacional previa en ese participante. No significa ausencia de estado de negocio o persistencia.

Shipping puede consultar cada pedido mediante identificador sin sesión y mantener estado del envío. Una conversación de reserva puede conservar correlación y plazos en otro componente. Hay que indicar qué estado hablamos y quién puede perderlo o reconstruirlo.

Communication frente a Dependency Structure

Orders → PaymentPort describe una dependencia de código. Orders que llama al adaptador en runtime describe interacción. Las direcciones y participantes representados pueden diferir porque el contrato interior y el ensamblaje separan conocimiento de ejecución.

Publicar PaymentAuthorized puede eliminar una referencia directa del productor al consumidor. El consumidor conserva dependencia del schema y semántica. Indirect communication no significa ausencia de coupling; HTTP tampoco demuestra independencia.

Una base de datos compartida puede permitir que unidades se transmitan información mediante escrituras y lecturas, además de persistirla. También introduce dependencia de schema, disponibilidad y reglas de concurrencia. No toda base compartida debe etiquetarse como un communication pattern: precisar su uso y dejar autoridad sobre datos para el eje posterior.

Communication frente a Coordination e Interoperability

Communication describe intercambio. Coordination pregunta cómo participantes alinean acciones, ordenan trabajo o conservan resultados e invariantes compartidos. Enviar PaymentRequested describe una comunicación; decidir quién controla el pedido, qué orden exige la reserva y cómo compensar un resultado parcial pertenece a coordinación.

Transportar JSON por HTTP puede permitir recepción sintáctica. interoperability pregunta si los participantes interpretan y utilizan correctamente la información. Payments que expresa autorizado y Orders que lo interpreta como capturado pueden comunicarse técnicamente y violar expectativas de negocio.

Ambas preguntas necesitan contratos, pero no son la misma. coordination desarrolla quién conduce el resultado y su recuperación; data-ownership aclara quién define y cambia estado autoritativo. El canal no decide ninguna de esas autoridades por sí solo.

Variantes y consecuencias del ejemplo común

Las cuatro responsabilidades pueden realizarse como módulos con llamadas locales, módulos con mensajería interna, servicios con llamadas síncronas de red o servicios con mensajería asíncrona. Es una división conceptual comparable; deployment, fallos y continuación necesitan analizarse nuevamente.

Un recorrido remoto chatty puede acumular latencia, tráfico y oportunidades de fallo. Buffering puede reducir espera inmediata y trasladarla al resultado final. operability y cost-efficiency ayudan a evaluar diagnóstico y recursos sin afirmar que una forma siempre sea superior.

Para decidir, describir un pedido exitoso, rechazo de pago, reserva vencida y respuesta perdida. Identificar qué espera cada participante, qué confirma cada señal, qué resultado puede quedar incierto y qué evidencia permite reconstruirlo. La comunicación elegida es defendible cuando conserva esas obligaciones, no porque utilice el mecanismo de moda.