Reglas y validación de plataforma

Esta guía describe el código actual de platform.rules y platform.validators en el repositorio. Las APIs y los namespaces aquí utilizados pueden diferir de los paquetes publicados anteriormente. Ambos proyectos tienen como destino .NET 10.

platform.rules expresa condiciones reutilizables y su estructura lógica. platform.validators ejecuta esa estructura y produce diagnósticos, reportes y estados de formulario. El consumidor aporta las condiciones propias de su aplicación, los mensajes y las consultas externas.

La separación existe porque comprobar una condición, relacionarla con otras y explicar un incumplimiento son responsabilidades distintas. Una regla puede responder si un correo tiene formato válido; la composición decide si debe evaluarse; el plan la vincula con una ruta y un diagnóstico; el reporte entrega el resultado a la aplicación. Lee primero por qué validar, componer y construir un plan si quieres entender las decisiones antes que la API.

Si buscas resolver una tarea concreta, comienza por los casos de uso.

Para escribir tu primera validación, usa el inicio rápido común: comienza con plataforma y después reutiliza el mismo plan en dominio. FieldSequence, mensajes predeterminados y lectura directa desde resultados reducen la configuración cotidiana.

Para aplicar estas composiciones a estados y operaciones de negocio, sigue la guía de dominio: comienza por las motivaciones, recorre invariantes y operaciones y termina con persistencia y diagnósticos. La revisión de consistencia explica qué garantías se comparten y qué diferencias deben conservarse.

Recorrido recomendado

1. Motivación: por qué validar, componer, representar un árbol y construir un plan.
2. Casos de uso: ejemplos completos con su flujo de ejecución.
3. Qué API usar: el camino cotidiano y las extensiones avanzadas.
4. Planes y composición: Field, reglas comunes, Add, Sequence, objetos e inclusión de planes.
5. Reglas técnicas y contratos: condiciones locales, asíncronas y contextuales; catálogo y tratamiento de null.
6. Diagnósticos y evidencia: resultados, rutas, mensajes y vistas para presentación.
7. Formularios y opciones: debounce, cancelación, versiones y cargas dependientes.
8. Ejemplo completo y decisiones de uso: validación de correo con consulta de unicidad y errores frecuentes.
9. Definiciones y árboles: identidad, apariciones, operadores y evaluación avanzada.
10. Migración: equivalencias entre APIs existentes y el camino recomendado.
11. Contratos avanzados: alcance y propósito de los tipos públicos.

Responsabilidades

Pieza	Responsabilidad	Resultado
IRule<T>	Comprobar una condición local	bool
RuleDefinition<T, C>	Dar identidad a una condición y capturar evidencia	ConditionResult al ejecutarse
RuleNode<T, C>	Representar una aparición u operador	Árbol reutilizable
ValidationRule	Asociar condición y diagnóstico	Definición de validación
ValidationBuilder<T, C>	Configurar composición y rutas	ValidationPlan<T, C>
RuleEvaluator	Ejecutar el árbol secuencialmente	RuleEvaluation
RuleDiagnostics	Proyectar incumplimientos a mensajes	Árbol de RuleDiagnostic
FormValidationSession<T, C>	Coordinar ediciones y publicación	Estados y eventos Changed

El plan conserva configuración; cada evaluación recibe su candidato y contexto. La sesión conserva el estado temporal de una interacción. Por eso conviene construir planes reutilizables y crear una sesión por formulario.

Un primer ejemplo

using Greencore.platform.rules;
using Greencore.platform.validators;

var required = ValidationRule.For("text.required", new RequiredRule<string?>(), "name.required", "El nombre es obligatorio.");
var plan = Validation.For<string?>().Add(required).Build();
var report = plan.Validate("   ");

Console.WriteLine(report.IsValid); // False
Console.WriteLine(report.Diagnostics[0].Message);

RequiredRule conoce la condición de presencia. La definición añade identidad, código y mensaje. El plan organiza la ejecución y el reporte permite consultar el resultado.

Para reglas habituales existe una forma abreviada que oculta las definiciones y deja visibles la composición y el mensaje:

var plan = Validation.For<Customer>()
    .Field(x => x.Email, field => field.Sequence(sequence => sequence
        .Required("El correo es obligatorio.")
        .Email("El correo no es válido.")))
    .Build();

El código se puede proporcionar como segundo argumento cuando una integración externa necesita un valor concreto. Las definiciones explícitas siguen siendo la opción para catálogos compartidos, evidencia tipada o reglas con una identidad propia.

Código de referencia

• Proyecto de reglas.
• Proyecto de validadores.
• Ejemplos ejecutables existentes.
• Contratos de composición.
• Contratos de árboles.
• Contratos de usabilidad.

Siguiente: Por qué validar, componer y construir un plan.