Evaluación del recorrido cotidiano

Índice · Inicio rápido · Convenciones

La evaluación compara tareas de código antes y después de la simplificación. No es un estudio con usuarios ni una medida de tiempo de aprendizaje. Los recuentos describen ejemplos concretos; no demuestran por sí solos que una API resulte intuitiva.

Decisiones implementadas

Se eligió FieldSequence frente a otro modificador sobre el builder del campo porque su alcance aparece en el nombre y permite un solo callback. No se añadió un segundo sinónimo.

Los mensajes predeterminados se incorporaron como sobrecargas sin mensaje. Esto conserva la distinción entre omitir un mensaje y proporcionar uno inválido, sin introducir configuración global.

La lectura de dominio se colocó junto a EntityValidator, para que el import del caso cotidiano también permita GetDiagnostics y ForField. Los accesos avanzados al árbol permanecen disponibles.

Se reutilizaron las fábricas de error existentes y se añadió ToResult. La mejora es de anidamiento y composición de la expresión, no una eliminación de la decisión sobre la categoría del error.

Seis tareas de comparación

Tarea	Antes	Después	Qué queda por aprender
Presencia y formato	Dos callbacks (Field y Sequence), dos mensajes obligatorios	Un callback (FieldSequence), mensajes opcionales	Presencia frente a formato
Consulta dependiente	Callback de campo y callback de secuencia	MustAsync dentro del mismo callback	Token, contexto y ValidateAsync
Mostrar errores	Comprobar fallo y entrar por Error.GetDomainDiagnostics()	result.GetDiagnostics()	Vacío significa ausencia de diagnósticos
Reutilizar en dominio	WithRules(plan)	Se conserva esa misma llamada	Elegir cuándo se necesita dominio
Rechazo de negocio	Result.Fail(new BusinessError(code, message))	BusinessError.Create(code, message).ToResult()	Categoría y código público
Personalizar regla	Mensaje obligatorio desde el inicio	Mensaje explícito solo donde hace falta	Localización y códigos estables

Criterios técnicos

• Equivalencia de FieldSequence con la composición explícita para entradas ausentes, formato inválido y consultas fallidas.
• No ejecución de consultas cuando falla un prerrequisito.
• Acumulación de errores entre campos independientes.
• Cancelación después de una hoja asíncrona sin ejecutar la siguiente.
• Mensajes y códigos de reglas predeterminadas, y conservación del código al personalizar solo el texto.
• Lectura de diagnósticos vacía en éxito, rutas inferidas y vistas conservadas en fallo.
• Rechazo de argumentos inválidos incluso cuando el resultado es satisfactorio.
• Conversión de errores sin perder identidad, categoría ni razones.
• Compilación y ejecución del inicio rápido completo.

Estos criterios están cubiertos por los contratos de plataforma, dominio y resultados del repositorio. Las convenciones anteriores permanecen disponibles y sus contratos se vuelven a ejecutar.

Límites y evaluación con lectores

La diferencia entre ValidationReport y Result<T> continúa existiendo. Tampoco se ha unificado artificialmente la semántica histórica de todos los builders ni se han reorganizado ensamblados.

Una futura revisión con lectores puede usar las seis tareas de la tabla: entregar el inicio rápido, permitir solo la documentación y registrar dudas, elecciones incorrectas y cambios necesarios. No se afirma que esa revisión humana ya se haya realizado.