Empieza por el intercambio
Imagina que un proveedor envía cada mañana un archivo de productos con product_id, price, currency y updated_at. El sistema lo acepta porque existen las cuatro columnas. Más tarde, un informe trata un precio negativo como válido, un identificador vacío genera duplicados y una moneda no admitida acaba dentro de un total.
La presencia de una columna no resuelve esos problemas. El contrato empieza por el intercambio: ¿qué necesita poder confiar el equipo receptor y qué puede prometer realmente el productor?
Separa estructura y expectativas de negocio
Una comprobación estructural pregunta si price es numérico. Una regla de negocio pregunta si puede ser negativo, si el cero tiene sentido y si incluye impuestos. Son preguntas diferentes y ambas necesitan una respuesta explícita.
En este ejemplo, el acuerdo podría exigir un identificador no vacío, precios numéricos no negativos, monedas de una lista acordada y marcas temporales con una zona horaria definida. Debe revisarlo alguien que conozca la relación con el proveedor, en lugar de deducirlo de unas pocas filas de muestra.
Documenta qué ocurre cuando algo falla
«Validar el archivo» deja una decisión importante sin resolver. Si una fila es incorrecta, ¿se rechaza toda la entrega, se aparta esa fila o se carga el conjunto con una advertencia? Cada opción cambia el significado de los informes posteriores.
Registra la gravedad de la regla, la acción ante un fallo y la persona que puede aprobar una excepción. Conserva la entrada original junto con el diagnóstico. Si transformas un valor, distingue esa transformación deliberada de una validación que solo informa de un problema. Las correcciones silenciosas dificultan las investigaciones posteriores.
Mantén la regla legible
Una regla declarativa y breve puede hacer más concreta la revisión. En la notación histórica de RuleScript, una restricción de precio se expresa así:
validate "price": number, min 0, max 10000,
on error "Price must be between 0 and 10000";Es un ejemplo documental del lenguaje anterior, no una instrucción para instalar un motor disponible. Su valor aquí es la legibilidad: el límite y el mensaje de error aparecen juntos. El máximo es una decisión de negocio de ejemplo, no una regla universal sobre precios.
Pide al responsable que explique ese límite. Si no tiene una fuente, el contrato habrá descubierto una decisión pendiente antes de que se convierta en lógica oculta.
Versiona el acuerdo, además del archivo
Supongamos que el proveedor empieza a admitir otra moneda. Añadir un valor a la lista puede ser un pequeño cambio de código con consecuencias importantes. Vincúlalo con una versión del contrato y registra su fecha de entrada en vigor. Identifica a los productores y consumidores que deben cambiar juntos.
Una revisión útil incluye ejemplos válidos, inválidos y casos límite como cero, una cadena vacía y un valor ausente. Usa datos sintéticos. Así ambos equipos pueden debatir el acuerdo sin compartir registros de producción.
Una lista breve para el primer contrato
- Identifica productor, consumidor y responsable.
- Describe los campos y su significado de negocio.
- Enumera restricciones, excepciones y fuentes de las decisiones.
- Define expectativas de entrega y tratamiento de errores.
- Asigna una versión y una fecha de vigencia.
- Acuerda ejemplos representativos que pasen y fallen.
No necesitas una gran plataforma para empezar. Un documento revisado y un conjunto versionado de comprobaciones ya pueden mejorar un intercambio frágil. El siguiente reto es mantener ese acuerdo conectado con las implementaciones que lo aplican.
Dónde encaja RuleGenius
RuleGenius empezó con validación y transformación legibles. El proyecto también plantea una pregunta más amplia: ¿cómo conservar el significado, la fuente, la revisión y la versión de una regla mientras avanzamos hacia su ejecución?
El proyecto está en desarrollo. Explora la referencia de RuleScript conservada o conoce la dirección actual del producto. Si gestionas un intercambio real con proveedores, queremos conocer ese proceso.