Apariencia
Plan de mejora en siete bloques
1. Ejecución fiable
Problema: una validación síncrona podía omitir reglas asíncronas, la ejecución asíncrona adelantaba todas las consultas y un conjunto inexistente podía producir éxito sin reglas.
Cambios: seleccionar el conjunto antes de ejecutar; rechazar nombres desconocidos y vacíos; rechazar Validate si ese conjunto contiene reglas asíncronas; ejecutar ValidateAsync en orden de registro y comprobar cancelación antes y después de cada regla. Un conjunto predeterminado vacío continúa siendo válido.
Aceptación: una regla asíncrona que rechaza al candidato nunca queda oculta tras éxito síncrono. Un token cancelado al terminar la última regla impide devolver éxito. Un conjunto local no queda bloqueado por reglas asíncronas registradas en otro conjunto.
2. Objetos de valor
Problema: default evita las fábricas de estructuras. Dos montos sin moneda podían sumarse con éxito.
Cambios: exponer IsInitialized en textos, moneda, monto y fecha; rechazar aritmética con cualquiera de los operandos sin inicializar; impedir calcular edad sin fecha; ofrecer representación vacía para textos y fechas no inicializados. Mantener cero por ciento y el género cero como valores admitidos.
Aceptación: las fábricas válidas conservan su comportamiento y las operaciones no convierten ausencia de moneda en dinero válido. No se cambia la naturaleza de los tipos de valor ni sus reglas de igualdad.
3. Entrada cotidiana
Problema: el consumidor debía conocer adaptadores para conectar el plan común con el dominio.
Cambios: añadir EntityValidator.For<T>(configure), ModelValidator.For<T, C>(configure), InvariantBuilder.Include(plan) y InvariantBuilder.WithRules(configure).
Aceptación: el mismo plan local se usa para validar un candidato y proteger un estado. Los callbacks reciben el builder común; los consumidores anteriores siguen compilando.
4. Composición explícita
Problema: Required y los prerrequisitos tienen significados distintos en las APIs existentes.
Cambios: orientar el recorrido cotidiano a Sequence, When, alternativas y ramas independientes del plan. Conservar el comportamiento de WithProperty.Required y los prerrequisitos globales de negocio. Documentar las equivalencias sin afirmar que todos los operadores son intercambiables.
Aceptación: una secuencia local-contextual omite la consulta cuando falla el plan local. El orden de registro por sí solo no se presenta como garantía de dependencia.
5. Diagnósticos e inspección
Problema: EntityValidator.Rules solo mostraba reglas síncronas y podía inducir una inspección incompleta.
Cambios: añadir Registrations, con regla síncrona o asíncrona, conjunto y IsAsync, conservando Rules por compatibilidad. Usar GetDomainDiagnostics como lectura común ya existente. Las razones de modelo implementan IDomainDiagnostic; las de árbol exponen también IRulePathDiagnostic. El proyecto de errores de modelo referencia los contratos de errores de entidad, como ya hace la familia de negocio.
Aceptación: la inspección muestra todas las apariciones en orden y una regla de campo adaptada conserva código y ruta. Las razones tipadas siguen disponibles.
6. Persistencia y reutilización
Problema: el puente de escritura requería TreeModelValidation y las especificaciones reconstruían nodos en cada evaluación.
Cambios: añadir una sobrecarga de persistencia para ModelValidator<T, C>, compartir la lógica de validación/escritura/adaptación y preparar el árbol de especificaciones durante su construcción. Copiar las colecciones de reglas y mantener resultados locales a cada llamada.
Aceptación: un fallo impide escribir; éxito escribe el candidato original; excepciones desconocidas se propagan; evaluaciones repetidas de una especificación no comparten fallos.
Límites deliberados: no cambiar IModelQueries de manera incompatible, no prometer transacciones automáticas y no intentar imponer inmutabilidad profunda mediante una restricción genérica que C# no ofrece.
7. Migración y verificación
Entregables: guía de selección, ejemplo completo, política de valores predeterminados, tabla de compatibilidad y script de nueve contratos.
Aceptación: compila la solución; pasan contratos de entidades, negocio, especificaciones, valores y las nuevas garantías. La guía distingue APIs existentes, incorporaciones y cambios observables. No se eliminan contratos públicos ni se introducen advertencias de obsolescencia generales.