Usabilidad y consistencia entre dominio y plataforma

Índice · Anterior: diagnósticos · Migración

Evaluación actual

El inicio rápido incorpora FieldSequence, mensajes predeterminados, lectura directa desde Result y conversión de errores mediante ToResult. La evaluación de tareas compara el esfuerzo de uso antes y después sin atribuirle resultados de un estudio con usuarios.

El camino más fácil de aprender es configurar con el builder común y adaptar el plan al dominio. Permite reutilizar composición, mensajes y rutas. Las APIs anteriores continúan disponibles, pero algunas palabras conservan significados distintos.

Tema	Garantía actual	Decisión del consumidor
Aceptación de objetos de valor	FromFactory reutiliza la fábrica	Elegir política completa o formato técnico
Plan local asíncrono	EntityValidator.WithRules lo admite	Ejecutar ValidateAsync
Invariantes	Solo planes síncronos	Separar consultas externas
Cancelación de planes adaptados	Token entre nodos y hacia hojas asíncronas	Propagarlo a servicios
Opciones	Entidad y modelo aceptan RuleEvaluationOptions	Elegir acumulación o cortocircuito
Presentación	ForField ofrece las mismas tres vistas	Elegir resumen o detalles
Agregar planes al modelo	WithRules repetido añade ramas independientes	Usar una secuencia para dependencias
Traza en éxito	Disponible en el plan y ModelValidator.EvaluateAsync	El resultado de entidad sigue siendo Result<T>

Diferencias intencionales

Required del builder común es independiente. Para presencia → formato usa Sequence. Required del antiguo builder de propiedades protege las reglas posteriores. When del builder común aplica un callback; el antiguo modifica la regla anterior. Evita traducir cadenas de llamadas palabra por palabra.

Los prerrequisitos de negocio son globales. Las dependencias del plan tienen el alcance de su composición. Las condiciones de operación no se incorporan automáticamente a cada invariante ni a cada escritura.

Los builders son mutables; los validadores con métodos With... devuelven otra instancia. Las entradas por callback reducen reasignaciones. Un plan vacío se rechaza; un validador de entidad o negocio vacío acepta; un modelo sin configurar rechaza la ejecución. Estos casos se mantienen por compatibilidad y deben elegirse conscientemente.

Límites que siguen importando

• La fábrica adaptada valida aceptación; no devuelve ni publica el valor normalizado.
• Las opciones no reescriben internamente reglas personalizadas o validadores antiguos de propiedades.
• La lectura común de diagnósticos depende de contratos ubicados en domain.entity.errors. Moverlos requiere otra migración de ensamblados.
• Una entidad con estado mutable puede ser modificada sin pasar por sus invariantes. El estado debe ser profundamente inmutable.
• NoRuleContext todavía aparece en declaraciones explícitas de tipos; var y las fábricas locales evitan exigirlo en el uso cotidiano.
• Los parámetros posicionales varían entre sobrecargas históricas. Usa argumentos nombrados para options y cancellationToken al combinar APIs.

Pruebas de paridad

El contrato de usabilidad compara aceptación de fábrica, plataforma y dominio; comprueba las tres vistas de alternativas; verifica omisión de hojas tras cancelación, planes asíncronos y opciones de ejecución. Los contratos anteriores protegen compatibilidad de razones tipadas y rutas de colecciones.

La documentación está organizada por decisiones de uso y ejemplos completos; el inventario de contratos se conserva en migración para consultas avanzadas.