Integrar un ERP de veinte años sin tocarlo
La capa anticorrupción permite que sistemas nuevos hablen con un ERP intocable sin heredar su modelo de datos. Qué va dentro y cómo mantenerla delgada.
Existe una categoría de sistema que nadie tiene permiso de cambiar. El ERP que funciona desde 2005. El motor de agendamiento cuyo autor se fue en 2013. El sistema de siniestros que está certificado, y recertificarlo cuesta más que el proyecto que intentas hacer.
Aun así tienes que integrarte con él. La pregunta es cómo hacerlo sin que el sistema nuevo herede treinta años de decisiones de modelado acumuladas.
Qué es realmente una capa anticorrupción
El término viene del diseño orientado al dominio, y es más literal de lo que suena. La capa existe para impedir que el modelo de un sistema corrompa el del otro.
En concreto: una frontera de traducción que habla el idioma del sistema heredado de un lado y el idioma de tu dominio del otro. Nada de tu lado de la frontera sabe que CUST_STAT_CD existe, que 9 significa activo, o que un cliente sin filas en CUST_ADDR es un registro provisional y no un cliente real.
Qué pertenece dentro
La capa se paga absorbiendo cinco tipos concretos de fealdad. Si no hace al menos tres de ellos, es un salto inútil.
| Asunto | Va en la capa | Ejemplo |
|---|---|---|
| Vocabulario | Sí | CUST_STAT_CD 9 se vuelve estado: activo |
| Forma | Sí | Seis tablas planas se vuelven un Cliente con lista de direcciones |
| Semántica ausente | Sí | Una fecha de fin nula significa abierta, no desconocida |
| Protocolo de acceso | Sí | SOAP, archivo de ancho fijo o lectura de una réplica |
| Límites de tasa y lote | Sí | El ERP acepta 5 peticiones por segundo antes de degradarse |
| Regla de negocio | No | La elegibilidad de descuento es de tu dominio, no de la frontera |
| Política de caché de los consumidores | No | Cada consumidor conoce su propio requisito de frescura |
Las dos últimas filas son donde estas capas se tuercen. En cuanto la lógica de negocio empieza a aterrizar en la frontera de traducción, deja de ser frontera y se convierte en una segunda aplicación de la que nadie es dueño.
La lectura es fácil; la escritura decide el diseño
Leer de un sistema intocable es sobre todo un problema de datos. Escribir en él es un problema de consistencia, y es lo que dirige todo el diseño.
Tres opciones, en orden creciente de lo que cuestan:
Escribir por la propia interfaz del ERP. Si expone una API o un formato de importación, úsalo y acepta su validación. Tu capa traduce y reenvía. Es la única opción que mantiene al ERP como fuente única de verdad, que es casi siempre lo que quieres.
Escribir a una cola que el ERP drena. Cuando el ERP solo ingiere por lotes, aceptas consistencia eventual y la haces explícita. El sistema nuevo debe poder mostrar un estado pendiente, y el usuario tiene que entender que "guardado" no es "contabilizado". Esa es una decisión de producto, no solo técnica.
Escribir directo en sus tablas. A veces es la única opción. Trátalo como último recurso, con una lista escrita de cada restricción y disparador que estás saltándote, porque ahora eres responsable de invariantes que la aplicación garantizaba.
Mantenerla delgada
Las capas anticorrupción crecen. Cada consumidor que necesita un campo más, cada caso de borde, cada "ya que estamos aquí" añade una línea. Después de dos años la capa es más grande que el servicio al que iba a proteger.
Tres hábitos la mantienen pequeña:
- Una capa por sistema heredado, no por consumidor. Varias capas de traducción sobre el mismo ERP significan varias interpretaciones del mismo campo, y van a discrepar.
- La capa no tiene base de datos. En el momento en que guarda estado, se vuelve fuente de verdad y deja de ser traducción. Cachear está bien; cachear con su propio camino de escritura, no.
- Un campo nuevo exige un consumidor con nombre. "Quizá lo necesitemos" es cómo una traducción de 40 campos se convierte en una de 300.
Cuándo no necesitas una
Si el sistema heredado ya expone una API limpia y bien modelada, envolverla añade un salto y un despliegue sin beneficio. Llámala directo.
Si estás reemplazando el sistema heredado en vez de integrarte con él, la capa todavía puede valer, porque se convierte en la fachada de una migración por partes. Pero entonces es un artefacto de migración con fecha de retiro, y hay que planificarla así.
Y si la "integración" es en realidad automatización de pantalla porque no hay interfaz alguna, el terreno es otro: mira RPA o integración por API.
Buena parte de lo que hacemos en modernización es esto. Si el sistema guarda datos regulados, las reglas de acceso de nuestras prácticas de seguridad aplican a la capa igual que a todo lo demás.