Abrir una API sin duplicar las reglas del negocio
Una nueva interfaz puede ocultar un problema: que la misma regla termine implementada en COBOL, en la API y en una aplicación web. Si cada versión evoluciona por su cuenta, las diferencias aparecen aunque todos los programas parezcan funcionar. Durante el diagnóstico localizamos dónde debe residir cada decisión.
Para una empresa de Barcelona que quiera habilitar nuevos canales, proponemos empezar por una operación concreta. Describimos qué solicita el consumidor y qué dato devuelve el sistema, evitando trasladar a la API todos los detalles internos de un fichero o una pantalla antigua.
La frontera entre consulta y modificación
Una consulta puede resolverse mediante una copia de datos si el negocio admite cierto retraso. Una modificación requiere aclarar quién confirma la operación y cuándo puede darse por terminada. Esa diferencia afecta a los errores, los tiempos de espera y la experiencia del usuario.
Revisamos especialmente el caso en el que el consumidor deja de esperar, pero el proceso COBOL termina más tarde. Volver a enviar la misma solicitud sin un identificador estable podría repetir el trabajo. La respuesta no se limita a aumentar un tiempo de espera: se diseña una forma de consultar el estado y reconocer la petición.
Extraer una función hacia .NET por etapas
Podemos estudiar una separación gradual: el sistema original conserva unas operaciones y el nuevo servicio asume otras. Antes de mover una regla a C# hay que conocer sus lecturas, escrituras y efectos secundarios. El código que parece un cálculo puro puede actualizar contadores o depender de una inicialización anterior.
La migración se valida con pruebas del contrato, no únicamente con pruebas internas de la clase nueva. Mantenemos ejemplos de peticiones y respuestas que puedan utilizar tanto el equipo del servicio como el de la aplicación consumidora.
Claude Code y OpenAI dentro de una revisión técnica
La asistencia de Claude, de Anthropic, o de herramientas de OpenAI puede utilizarse para proponer interfaces y preparar casos de prueba. El criterio de aceptación sigue siendo el comportamiento observado y acordado. Un contrato redactado con claridad puede contener una decisión incorrecta si no se contrasta con el origen.
En el proyecto se establecen permisos sobre el repositorio y límites de información. No hace falta compartir una base de clientes para definir un ejemplo de petición. Las muestras se preparan de forma que reproduzcan las estructuras necesarias sin exponer datos que no aportan valor a la prueba.
Una integración observable desde ambos lados
Al publicar una operación, dejamos trazas que permitan relacionar la petición de la aplicación nueva con la ejecución en el sistema existente. Se acuerda qué registrar, durante cuánto tiempo operativo se necesita y qué datos no deben aparecer en los mensajes de diagnóstico.
Un ejemplo de alcance sería ofrecer una consulta de estado de pedido sin cambiar todavía la facturación. Es una situación hipotética que ayuda a separar responsabilidades; no un caso de éxito atribuido a una empresa barcelonesa. La siguiente operación se incorpora cuando la primera tenga un comportamiento verificable.