Forem: Romny Duarte

FluentValidation en .NET 10 sin ensuciar tus entidades (Clean Architecture + MediatR)

Romny Duarte — Sun, 19 Apr 2026 15:23:19 +0000

Hola a Todos. Uno de los errores más comunes al construir aplicaciones en .NET es mezclar validaciones directamente en las entidades usando atributos como:

[Required]
[MaxLength]
[EmailAddress]

Aunque esto funciona, introduce varios problemas:

❌ Acopla el dominio a frameworks como ASP.NET
❌ Dificulta las pruebas unitarias
❌ Mezcla responsabilidades
❌ Reduce reutilización

En este artículo veremos cómo usar FluentValidation de forma correcta en .NET 10, siguiendo Clean Architecture y usando MediatR, manteniendo el dominio completamente limpio.

🧨 El problema: entidades contaminadas

public class User
{
    public string Name { get; set; }

    [Required]
    [EmailAddress]
    public string Email { get; set; }
}

¿Qué está mal aquí?

La entidad depende de System.ComponentModel.DataAnnotations
No puedes reutilizarla fácilmente fuera de ASP.NET
Las validaciones no son fácilmente testeables de forma aislada

✅ Principio clave: dominio limpio

En Clean Architecture, el dominio debe ser:

Independiente
Puro
Libre de frameworks

Entidad correcta

public class User
{
    public string Name { get; set; }
    public string Email { get; set; }
}

Sin validaciones, sin atributos y sin dependencias externas.

🧠 ¿Dónde deben ir las validaciones?

En la Application Layer, no en el dominio.

Ahí es donde FluentValidation realmente brilla.

🔥 Instalación

dotnet add package FluentValidation
dotnet add package FluentValidation.DependencyInjectionExtensions
dotnet add package MediatR
dotnet add package MediatR.Extensions.Microsoft.DependencyInjection

✍️ Caso real: crear usuario con CQRS + MediatR

1. Command

using MediatR;

public record CreateUserCommand(string Name, string Email) : IRequest<Guid>;

2. Validator

using FluentValidation;

public class CreateUserCommandValidator : AbstractValidator<CreateUserCommand>
{
    public CreateUserCommandValidator()
    {
        RuleFor(x => x.Name)
            .NotEmpty()
            .WithMessage("El nombre es obligatorio")
            .MaximumLength(100);

        RuleFor(x => x.Email)
            .NotEmpty()
            .WithMessage("El email es obligatorio")
            .EmailAddress()
            .WithMessage("Email inválido");
    }
}

Aquí está la gran ventaja: las reglas viven fuera del dominio.

⚙️ Handler de MediatR

using MediatR;

public class CreateUserCommandHandler : IRequestHandler<CreateUserCommand, Guid>
{
    public async Task<Guid> Handle(CreateUserCommand request, CancellationToken cancellationToken)
    {
        var user = new User
        {
            Name = request.Name,
            Email = request.Email
        };

        // Simulación de persistencia
        return Guid.NewGuid();
    }
}

En este punto el request ya llega validado gracias al pipeline.

🧩 Validación automática con MediatR Pipeline Behavior

Aquí es donde el enfoque se vuelve mucho más potente.

En vez de validar manualmente en cada handler, puedes centralizar toda la validación usando un PipelineBehavior.

using FluentValidation;
using MediatR;

public class ValidationBehavior<TRequest, TResponse> : IPipelineBehavior<TRequest, TResponse>
    where TRequest : notnull
{
    private readonly IEnumerable<IValidator<TRequest>> _validators;

    public ValidationBehavior(IEnumerable<IValidator<TRequest>> validators)
    {
        _validators = validators;
    }

    public async Task<TResponse> Handle(
        TRequest request,
        RequestHandlerDelegate<TResponse> next,
        CancellationToken cancellationToken)
    {
        if (_validators.Any())
        {
            var context = new ValidationContext<TRequest>(request);

            var validationResults = await Task.WhenAll(
                _validators.Select(v => v.ValidateAsync(context, cancellationToken))
            );

            var failures = validationResults
                .SelectMany(r => r.Errors)
                .Where(f => f != null)
                .ToList();

            if (failures.Any())
            {
                throw new ValidationException(failures);
            }
        }

        return await next();
    }
}

Con esto, cualquier command que tenga un validator se valida automáticamente.

🧱 Registro en Program.cs

using FluentValidation;
using MediatR;

builder.Services.AddMediatR(cfg =>
{
    cfg.RegisterServicesFromAssembly(typeof(CreateUserCommand).Assembly);
});

builder.Services.AddValidatorsFromAssembly(typeof(CreateUserCommandValidator).Assembly);

builder.Services.AddTransient(typeof(IPipelineBehavior<,>), typeof(ValidationBehavior<,>));

🌐 Uso desde Minimal API

app.MapPost("/users", async (CreateUserCommand command, IMediator mediator) =>
{
    var result = await mediator.Send(command);
    return Results.Ok(result);
});

No necesitas escribir validaciones manuales en controllers ni endpoints.

🧪 Testing del Validator

Una de las grandes ventajas de FluentValidation es que puedes probar las reglas fácilmente.

using FluentValidation.TestHelper;
using Xunit;

public class CreateUserCommandValidatorTests
{
    private readonly CreateUserCommandValidator _validator = new();

    [Fact]
    public void Should_Have_Error_When_Email_Is_Invalid()
    {
        var command = new CreateUserCommand("Romny", "correo-invalido");

        var result = _validator.TestValidate(command);

        result.ShouldHaveValidationErrorFor(x => x.Email);
    }
}

⚖️ Validar DTO o validar entidad

Una de las preguntas más comunes es: ¿debo validar la entidad o el DTO?

La recomendación es validar Commands o DTOs.

¿Por qué?

Representan la entrada del sistema
No contaminan el dominio
Mantienen mejor separación de responsabilidades
Encajan mejor con CQRS

🚫 Anti-patrones comunes

Validar en Controllers

if (string.IsNullOrEmpty(request.Email))
{
    throw new Exception("Email inválido");
}

Validar en entidades

[Required]
public string Email { get; set; }

Mezclar validación con lógica de negocio

if (request.Email.Contains("gmail"))
{
    // lógica de negocio
}

✅ Buenas prácticas

Validar en Application Layer
Usar FluentValidation
Validar Commands y DTOs
Integrar validación automática con MediatR
Mantener el dominio limpio
Escribir pruebas unitarias para validadores

🧠 Conclusión

Usar FluentValidation con Clean Architecture y MediatR en .NET 10 te permite:

Separar responsabilidades correctamente
Tener validaciones testeables
Centralizar validaciones
Mantener el dominio limpio
Escalar la arquitectura sin deuda técnica

Si estás construyendo sistemas modernos en .NET, este enfoque ya no es un extra: es prácticamente el estándar.

🎯 TL;DR

No pongas validaciones en entidades
Usa FluentValidation en Application Layer
Integra con MediatR usando Pipeline Behavior
Valida Commands y DTOs, no Domain Models
Mantén el dominio limpio

Espero con esto poder ayudarlos.

Sl2

Romny

NET9: Swagger no compatible [Alternativas]

Romny Duarte — Mon, 13 Jan 2025 19:56:40 +0000

Hola a Todos.

Continuando con el post anterior en donde mirábamos como desde la versión de NET 8 y NET 9 la configuración para usar Swagger ya no era posible, es este post vengo a comentarles ciertas alternativas para poder resolver esto.

NSwag

Con este paquete, NSWag ofrece la capacidad de crear un cliente como Swagger como Swashbuckle para poder usar tu enpoint.

Lo primero es importar el paquete NSwag.AspNetCore, luego llamaremos a UseSwaggerUi en el archivo Program.cs y le pasamos como parametro el archivo json de la especificacion OpenApi.

Ya con esto solo basta con ir a la ruta /swagger

Algo importante de NSwag es que ofrecen NSwagStudio una solución para trabajar con la especificación OpenApi y generar código C#.

Si te gusta la opción tradicional lo único que tienes que hacer es agregar el paquete Swashbuckle.AspNetCore, el paquete sigue funcionando, pero eventualmente con el tiempo creo que no.

Basta con realizar estas modificaciones

Con esto ya podemos ejecutar nuestra aplicación.

Espero con esto poder ayudarlos.

Sl2

Romny

NET9: Swagger no compatible

Romny Duarte — Mon, 13 Jan 2025 14:59:48 +0000

Hola a Todos.

Desde NET8 y NET9 el componente de Swagger no funciona. Cuando creamos un proyecto viene predefinido habilitar la compatibilidad OpenApi.

Cuando revisamos la configuración del Program.cs observamos lo siguiente.

Si ejecutamos la aplicacion e intentamos navegar por /swagger obtenemos un error 404.

Para validar los endpoints es necesario abrir la ruta /openapi/v1.json

El componente Swagger es utilizado ampliamente en el mundo del desarrollo para realizar pruebas de los endpoints que estamos construyendo, es una herramienta bastante importante y necesaria.

Ahora bien, entonces como hacemos para probar los endpoints, muchos se preguntarán. De primera mano podemos usar Postman, en otra entrada del blog hablaremos de las opciones que tendremos para resolver esto.

En Postman basta con ir a la opción de Import, copiar toda la definición del file /openapi/v1.json. Con esto ya podremos probar nuestros endpoints.

Sl2

Romny

Iniciando nuevamente...

Romny Duarte — Mon, 13 Jan 2025 02:20:25 +0000

Hola a Todos, Mi nombre es Rommy, Ingeniero de sistemas, especialista en Ingeniería del software. Oriundo de Yopal, Casanare (Colombia). Con unos buenos 18 años de experiencia en el desarrollo de software desde aplicaciones de Escritorio, Web Site, App Mobile y como no todo lo relacionado en Cloud.

Los últimos años he trabajado como Arquitecto de Soluciones, enfocado en AWS, pero también con conocimiento en Azure y GCP.

Iniciando nuevamente en los blogs, la plataforma anterior que manejaba Geeks.ms ya dejo de funcionar y bueno perdí mi histórico de blogs que tenía desde el 2018. Si lo quieren consultar lo pueden hacer a través de la plataforma de archive.org Pero bueno, iniciando este 2025 con este nuevo proyecto.

Soy muy fullstack, por ende, comparto de muchos temas. Así que nos vemos en este espacio.

Sl2

Romny
Linkedin