Conectar servicios y dependencias

El restaurante puede tener una cocina impecable y quedarse sin pedidos si falla la comunicación con el salón. Una aplicación también depende de relaciones que no aparecen al mirar únicamente sus archivos.

Una dependencia puede ser una biblioteca, una base de datos, otro servicio o una condición de red. Para estudiar una entrega conviene distinguir las que se necesitan para construir de las que se necesitan mientras la aplicación atiende.

Lo que el paquete no lleva consigo

Nuestro pedido ficticio calcula importes sin consultar otras plataformas. Imaginemos ahora que incorpora un servicio de inventario: antes de aceptar una compra, pregunta si quedan unidades. El cálculo puede seguir funcionando, pero la decisión de aceptar el pedido tendrá una condición adicional.

La integración debe definir el dato esperado y qué hacer si no llega. ¿Una respuesta vacía significa «sin existencias» o «no pude consultar»? Si tratamos ambos casos igual, un fallo técnico puede convertirse en una información falsa para el usuario.

Tiempo, compatibilidad y efectos

• Tiempo: una consulta necesita un límite de espera y una respuesta comprensible cuando se supera.
• Compatibilidad: cambiar el formato de un dato puede afectar a quien lo recibe, aunque cada servicio funcione por separado.
• Reintentos: repetir una consulta no siempre equivale a repetir una acción. Una operación que crea un pedido podría duplicarlo.
• Accesos: las credenciales y la red deben permitir la operación prevista, sin ampliar permisos innecesariamente.

Para las operaciones con efectos, identificar cada solicitud y controlar los duplicados puede formar parte del diseño. No existe una respuesta universal: hay que considerar qué acción se intenta, quién conserva su estado y qué ocurre al repetirla.