DEV Community: Beto Ramirez

"Blindaje, Frontend y Evolución: Tests de Arquitectura, SQLite in-memory y el Camino a Modular Monolith (Parte 3)

Beto Ramirez — Sun, 27 Sep 2026 20:52:55 +0000

Llegamos a la última entrega de nuestra serie sobre Vertical Slice Architecture (VSA) en .NET.

En la Parte 1, eliminamos los proyectos innecesarios y sentamos las bases con Minimal APIs y auto-descubrimiento. En la Parte 2, escribimos código de producción: handlers cohesivos, persistencia directa con EF Core, validación con filtros y eventos desacoplados.

Pero cualquier arquitecto o desarrollador senior se estará haciendo la pregunta decisiva:

«Al meter todo en un solo proyecto Web API, eliminaste los muros del compilador. ¿Qué impide que un desarrollador con prisa llame a un handler privado de otro slice o cree dependencias circulares? ¿Cómo testeamos esto sin volvernos locos? ¿Cómo se conecta con el frontend? ¿Y qué pasa si la aplicación crece a 100 slices?»

En este artículo cerramos el círculo: blindaje con tests de arquitectura automáticos, testing honesto sin mocks de repositorio, generación de contratos hacia TypeScript y la hoja de ruta para evolucionar hacia un Monolito Modular sin reescribir tu sistema.

Testing sin mentiras: Dile adiós a los mocks de repositorio

En proyectos tradicionales con Clean Architecture, las pruebas unitarias suelen lucir así:

// El clásico test que prueba el mock, no tu código:
var mockRepo = new Mock<IProductRepository>();
mockRepo.Setup(r => r.GetByIdAsync(It.IsAny<Guid>())).ReturnsAsync(new Product());

var service = new ProductService(mockRepo.Object);
await service.DoSomethingAsync(id);

mockRepo.Verify(r => r.GetByIdAsync(id), Times.Once); // "Probamos que llamamos al mock"

¿Qué acabas de probar? Que si llamas a un método ficticio, ese método ficticio devuelve lo que tú mismo le dijiste que devolviera.

No probaste si tu consulta LINQ era válida, si rompía por una columna nula, si el mapping fallaba o si las restricciones de clave foránea se cumplían. Ese test miente por omisión.

La alternativa honesta: SQLite in-memory con esquema real

En nuestra plantilla, no hay repositorios que mockear porque no hay repositorios que escribir. Los handlers reciben AppDbContext.

Para testearlos de forma ultrarrápida y realista, creamos un helper TestDb.Create() que levanta una base de datos SQLite in-memory con todas las tablas y configuraciones reales creadas en memoria:

namespace VsaTemplate.Tests.Common;

public static class TestDb
{
    public static AppDbContext Create()
    {
        var connection = new SqliteConnection("Data Source=:memory:");
        connection.Open();

        var options = new DbContextOptionsBuilder<AppDbContext>()
            .UseSqlite(connection)
            .Options;

        var db = new OwnedConnectionDbContext(options, connection);
        db.Database.EnsureCreated(); // Aplica el schema real al instante
        return db;
    }
}

Cómo luce un test unitario real del Handler

Observa tests/Features/Products/CreateProductTests.cs:

public class CreateProductTests
{
    [Fact]
    public async Task Creates_the_product_when_the_data_is_valid()
    {
        // 1. Arrange: BD real en memoria y mock solo para la frontera (EventDispatcher)
        await using var db = TestDb.Create();
        var fakeDispatcher = new Mock<IEventDispatcher>();

        // El handler se construye con new directo: ¡sin interfaces, sin DI container!
        var handler = new CreateProductHandler(db, fakeDispatcher.Object);

        // 2. Act
        var request = new CreateProduct.Request("Teclado Mecánico", 99m);
        var result = await handler.Handle(request, CancellationToken.None);

        // 3. Assert: Comprobamos el resultado Y que la fila realmente existe en la BD
        Assert.Equal("Teclado Mecánico", result.Value!.Name);
        Assert.Single(db.Products);
    }
}

Corre en milisegundos.
Ejecuta SQL real.
Solo mockeas las verdaderas fronteras externas (como IEventDispatcher o pasarelas de pago).

Testear validadores es aún más simple

Como los validadores de FluentValidation viven en el slice, se prueban como funciones puras:

[Fact]
public void The_validator_rejects_the_empty_name()
{
    var result = new CreateProduct.Validator()
        .Validate(new CreateProduct.Request("   ", 99m));

    Assert.False(result.IsValid);
    Assert.Contains(result.Errors, e => e.PropertyName == "Name");
}

Sin base de datos, sin servidor HTTP, sin complejidad.

Dos niveles de tests

Unitarios por Slice (tests/Features/): Construyes el handler con new, pasas TestDb y pruebas la lógica interna de inmediato.
Integración HTTP (tests/Integration/): Usamos WebApplicationFactory (ApiFactory) para levantar la API completa, reemplazando la base de datos por SQLite in-memory y enviando peticiones HTTP reales. Esto valida routing, serialización JSON, middleware de autenticación, rate limiting y filtros.

Tests de Arquitectura: El guardián de las reglas

La mayor crítica a Vertical Slice Architecture es:

«Al no tener proyectos separados, cualquiera puede meter un using VsaTemplate.Features.Orders; dentro de Features.Products y nadie se va a dar cuenta en el code review».

Y es una crítica válida. Una violación de arquitectura en un solo proyecto es una línea invisible que se cuela en silencio.

Para resolver esto de raíz, usamos NetArchTest.Rules. Convertimos nuestras reglas arquitectónicas en pruebas automatizadas de xUnit que corren con dotnet test y rompen el build en el Pull Request si alguien comete una infracción.

Observa cómo se ve en tests/Architecture/ArchitectureTests.cs:

[Fact]
public void A_slice_does_not_use_use_cases_from_another_slice()
{
    var failures = new List<string>();

    foreach (var slice in Slices())
    {
        // Obtiene todos los tipos de casos de uso de los demás slices
        var foreignUseCases = Slices()
            .Where(other => other != slice)
            .SelectMany(UseCaseTypeNames)
            .ToArray();

        // Verifica que este slice NO tenga dependencia sobre los casos de uso ajenos
        var result = Types.InAssembly(Api)
            .That().ResideInNamespaceStartingWith($"VsaTemplate.Features.{slice}")
            .ShouldNot().HaveDependencyOnAny(foreignUseCases)
            .GetResult();

        if (!result.IsSuccessful)
            failures.AddRange(result.FailingTypes.Select(t => $"  {t.FullName}"));
    }

    Assert.True(failures.Count == 0,
        "Estos tipos usan casos de uso de otro slice. Lo público de un slice es su " +
        "Domain (consultas) y sus Contracts (eventos); para lo demás, comunícate por " +
        $"eventos (README, regla 1):\n{string.Join('\n', failures)}");
}

Las 6 reglas vigiladas automáticamente:

Un slice no usa los casos de uso de otro slice: Vigila automáticamente cada carpeta dentro de Features/.
Common no usa casos de uso de los slices: La infraestructura compartida jamás debe depender de la lógica de negocio.
Toda clase *Endpoints implementa IFeatureEndpoints: Si a un dev se le olvida implementar la interfaz, el test falla y le avisa que sus rutas no se iban a registrar.
Los event handlers viven en Features, no en Common: Escuchar eventos es responsabilidad de negocio.
Los contratos anidados se llaman Request, Response o Validator: Garantiza coherencia en toda la solución y nombres limpios para el generador de TypeScript.
Todo handler queda registrado por convención: Si alguien crea un handler privado o que no cumpla la convención de nombres de Scrutor, el test lo detecta antes de que cause un error HTTP 500 en runtime.

Lección de oro: Un test de arquitectura que nunca falla no protege nada. Durante el desarrollo de la plantilla creamos clases con violaciones a propósito para confirmar que el test fallaba y arrojaba mensajes explicativos y educativos para el desarrollador infractor.

Contrato directo hacia el Frontend (OpenAPI → TypeScript)

¿Cuántas veces has tenido que escribir en Angular o React una interfaz interface ProductDto { id: string; name: string; price: number; } que ya tenías escrita en C#? Y a las dos semanas, alguien renombra un campo en el backend y el frontend explota silenciosamente.

No hay que duplicar modelos a mano: OpenAPI es el puente natural.

El desafío de VSA con OpenAPI: Colisión de nombres

En VSA, todos los slices anidan sus records y los llaman igual: CreateProduct.Request, PlaceOrder.Request.

Por defecto, el generador OpenAPI de ASP.NET Core solo toma el nombre de la clase interna (Request), provocando una colisión de nombres inmediata en el archivo openapi.json.

En Common/OpenApi/OpenApiRegistration.cs lo resolvimos configurando CreateSchemaReferenceId:

public static IServiceCollection AddOpenApiDocument(this IServiceCollection services) =>
    services.AddOpenApi(options =>
    {
        // Si el tipo está anidado, combinamos el nombre del padre con el hijo:
        // CreateProduct + Request = "CreateProductRequest"
        options.CreateSchemaReferenceId = typeInfo =>
            typeInfo.Type.DeclaringType is { } owner
                ? $"{owner.Name}{typeInfo.Type.Name}"
                : OpenApiOptions.CreateDefaultSchemaReferenceId(typeInfo);
    });

Métodos limpios con `.WithName()` y `TypedResults`

Al mapear el endpoint con .WithName(nameof(CreateProduct)), le asignamos un operationId explícito. Y al usar Task<Results<Created<Response>, ValidationProblem>>, ASP.NET Core infiere automáticamente los esquemas de respuesta HTTP 201 y HTTP 400 sin tener que llenar los endpoints de atributos [ProducesResponseType].

Generación automática en Angular

En el frontend (Angular en este caso), un simple comando lee el JSON generado y crea clientes y tipos con tipado estricto:

npx ng-openapi-gen --input ./openapi/VsaTemplate.json --output src/app/api

El ciclo de feedback es perfecto:

Modificas un record en C#.
Compilas la API (dotnet build actualiza el JSON de OpenAPI).
Corres ng-openapi-gen.
El compilador de TypeScript te marca en rojo exactamente qué pantalla de Angular quedó desactualizada.

Registro de Decisiones de Arquitectura.

Para tener una visión de todas las decisiones técnicas tomadas en la plantilla, esta tabla resume el por qué detrás de cada elección:

#	Decisión Técnica	Justificación Pragmática
1	VSA en un solo proyecto	La complejidad se paga por slice, no por proyecto. Elimina fricción innecesaria.
2	Endpoints separados de la lógica	El archivo `Endpoints.cs` actúa como tabla de rutas del slice; el handler queda libre de HTTP.
3	Handlers sin interfaces	Una interfaz sin segunda implementación es pura ceremonia.
4	Registro por convención con Scrutor	Cero configuración manual en `Program.cs`. Un test de arquitectura vigila que nada quede fuera.
5	Interfaces solo en fronteras	`TimeProvider`, `IEventDispatcher`, pasarelas de pago y proveedores externos.
6	Sin MediatR	Minimal APIs despacha directo; los Endpoint Filters cubren los cross-cutting concerns.
7	Tests con SQLite in-memory	Prueba el LINQ y SQL real; elimina la necesidad de repositorios ficticios.
8	Dispatcher de eventos propio (~40 líneas)	Desacopla slices in-process sin librerías externas ni problemas de licenciamiento.
9	Eventos en `Contracts/`	Frontera explícita y verificable por namespace entre features.
10	OpenAPI emitido en build + TS	Contrato de tipos compartido entre backend y frontend sin desincronización manual.
11	Tests de arquitectura con NetArchTest	Las convenciones se vigilan con tests automáticos en el CI/CD, no con policías en review.
12	EF Core Config en el slice, Migraciones en Common	La config cambia con la entidad; las migraciones son globales por diseño del `ModelSnapshot` de EF.
13	FluentValidation en Endpoint Filter	Menos código por slice; el handler solo recibe peticiones válidas.
14	dotnet-ef como tool local	El repositorio fija sus versiones de herramientas de desarrollo sin tocar la máquina global del dev.

El camino de crecimiento: De Slice a Monolito Modular y Microservicios

El mayor temor al comenzar con Vertical Slice Architecture es:

«¿Qué pasa cuando la aplicación crezca a 50 modelos y 200 casos de uso? ¿Nos quedaremos atrapados?»

La respuesta es que VSA ofrece el camino de crecimiento más natural y sin saltos traumáticos:

      FASE 1: SLICE SIMPLE (HOY)
      Un proyecto Web API.
      Slices en carpetas `Features/`.
      Dispatcher in-process.
                 │
                 ▼ (Un feature crece mucho en complejidad o equipo)
      FASE 2: MÓDULO INDEPENDIENTE
      Se extrae la carpeta a su propio proyecto de clase o DLL.
      DbContext propio y migraciones propias.
      Frontera ya lista gracias a `Contracts/`.
                 │
                 ▼ (Los módulos requieren comunicación resiliente)
      FASE 3: MONOLITO MODULAR
      Reemplazas el dispatcher in-process por Wolverine o MassTransit.
      Outbox pattern, reintentos y mensajería asíncrona.
                 │
                 ▼ (Solo si un módulo requiere despliegue/escala independiente)
      FASE 4: MICROSERVICIO
      El módulo se despliega en su propio contenedor/proceso.
      Cero refactorización de lógica de negocio.

Hoy: Todo vive en un solo proyecto, pero perfectamente ordenado por slices.
Un feature crece demasiado: Imagina que el módulo Billing crece y tiene su propio equipo asignado. Como su configuración de EF Core, sus handlers y sus contratos ya viven en su carpeta, convertirlo en un módulo (proyecto de biblioteca de clases separado) es una mudanza limpia y barata.
Comunicación resiliente: Cuando varios módulos necesitan coordinarse de forma asíncrona y transaccional, reemplazas el dispatcher simple por Wolverine. Como tus handlers ya son clases con un método Handle, no tienes que reescribir nada.
Microservicio (solo si hace falta): Si después de todo eso, el módulo de Facturación necesita escalar a 10 instancias en Kubernetes mientras el resto corre en 1, lo extraes como servicio independiente.

La regla de oro: Nunca te saltes etapas. Empezar con microservicios desde el día uno es comprar complejidad antes de tener el problema. Con VSA tienes agilidad inmediata hoy y una puerta abierta al futuro sin deuda técnica.

Conclusión de la serie

A lo largo de estas 3 entregas hemos demostrado que:

No necesitas 5 proyectos para hacer software profesional en .NET.
Puedes tener código limpio, testeable y desacoplado sin caer en la trampa del boilerplate infinito.
Con las herramientas modernas de C# (.NET 10 / C# 13-14), Minimal APIs, Scrutor, FluentValidation y NetArchTest, el desarrollo backend vuelve a ser divertido, ágil y legible.

Ponlo en práctica hoy mismo

La plantilla completa está lista para que la uses en tus proyectos personales o en tu empresa:

# Instalar el template desde GitHub
dotnet new install https://github.com/betoramiz/vsa-template.git

# Crear un proyecto nuevo
dotnet new vsa-api -n MiEmpresa.Api -o MiEmpresa.Api --IncludeSampleFeature

👉 Repositorio oficial: github.com/betoramiz/vsa-template

👉 Wiki con detalles arquitectónicos: Documentación en GitHub Wiki

¡Dejame conocer tu experiencia!

¿Te ha tocado sufrir soluciones con decenas de capas y proyectos vacíos? ¿Te animarías a probar Vertical Slice Architecture en tu próximo proyecto en .NET?

¡Deja tus reflexiones, preguntas o discrepancias en los comentarios! Comparte esta trilogía con tu equipo si crees que les ahorrará horas de boilerplate. ¡Hasta la próxima!

Anatomía de un Slice en Producción: Handlers sin interfaces, EF Core sin repositorios y eventos desacoplados (Parte 2)

Beto Ramirez — Sun, 27 Sep 2026 20:37:00 +0000

En la Parte 1 de esta serie, exploramos por qué Clean Architecture tradicional suele agotar a los equipos con su laberinto de proyectos y capas. Vimos la filosofía de Vertical Slice Architecture (VSA): la complejidad se paga por slice, no por proyecto, y cómo organizar Minimal APIs limpias y auto-descubiertas.

Pero ahora viene lo bueno: abrir el capó del motor y escribir código de producción.

En este artículo responderemos a las preguntas que todo desarrollador .NET se hace al enfrentarse a VSA por primera vez:

¿Cómo estructuro un caso de uso para no terminar con un archivo inmanejable de 1000 líneas?
¿Dónde quedaron las interfaces? ¿Es pecado no poner ICreateProductService?
¿Por qué dejamos de usar MediatR en pleno 2026?
¿Cómo persistimos con Entity Framework Core sin caer en la trampa del patrón repositorio genérico?
¿Cómo validamos peticiones y cómo hacemos que dos slices se comuniquen sin acoplarse?

Vamos paso a paso.

Anatomía de un caso de uso: Todo lo que cambia junto, vive junto

En Clean Architecture, para entender qué hace "Crear Producto", tienes que abrir la entidad en un proyecto, el DTO en otro, el validador en otro y el handler en otro.

En VSA aplicamos el principio de cohesión espacial: todo lo relacionado con ese caso de uso específico vive en un único archivo: Features/Products/CreateProduct.cs.

Observa el código completo de producción:

using FluentValidation;
using Microsoft.AspNetCore.Http.HttpResults;
using VsaTemplate.Common.Events;
using VsaTemplate.Common.Persistence;
using VsaTemplate.Features.Products.Contracts;
using VsaTemplate.Features.Products.Domain;

namespace VsaTemplate.Features.Products;

// 1. Contratos y validación agrupados bajo el nombre del caso de uso
public static class CreateProduct
{
    public record Request(string Name, decimal Price);
    public record Response(Guid Id, string Name, decimal Price);

    public class Validator : AbstractValidator<Request>
    {
        public Validator()
        {
            RuleFor(x => x.Name).NotEmpty().MaximumLength(200);
            RuleFor(x => x.Price).GreaterThan(0);
        }
    }
}

// 2. La lógica del caso de uso en su clase Handler contigua
public class CreateProductHandler(AppDbContext db, IEventDispatcher eventDispatcher)
{
    public async Task<Created<CreateProduct.Response>> Handle(
        CreateProduct.Request request, 
        CancellationToken ct)
    {
        var product = new Product
        {
            Id = Guid.NewGuid(),
            Name = request.Name.Trim(),
            Price = request.Price,
        };

        db.Products.Add(product);
        await db.SaveChangesAsync(ct);

        // Publicar evento in-process para otros interesados
        await eventDispatcher.Publish(new ProductCreated(product.Name, product.Price), ct);

        return TypedResults.Created(
            $"/products/{product.Id}",
            new CreateProduct.Response(product.Id, product.Name, product.Price));
    }
}

Analicemos la genialidad de esta estructura:

Clase estática contenedora: CreateProduct actúa como un espacio de nombres local. Sus DTOs son CreateProduct.Request y CreateProduct.Response. Se acabaron los nombres kilométricos como CreateProductCommandDto o CreateProductResultModel.
Constructor primario de C#: Las dependencias (AppDbContext, IEventDispatcher) entran directamente en la firma de CreateProductHandler(...). Sin campos privados private readonly, sin boilerplate.
Todo a la vista: En 45 líneas tienes el contrato de entrada, el contrato de salida, las reglas de validación y la lógica de ejecución. Si el negocio te pide cambiar el largo máximo del nombre a 300 caracteres, modificas este archivo y nada más.

El fin de las interfaces ceremoniales: Cero interfaces para tus handlers

Si vienes del mundo corporativo de .NET, tu instinto probablemente te grite:

«¡Espera! ¿Dónde está ICreateProductHandler? ¿Cómo vas a registrar eso en el contenedor de dependencias? ¿Cómo lo vas a testear?»

Hablemos con honestidad:

Una interfaz sirve para intercambiar implementaciones en tiempo de ejecución. Un caso de uso de negocio tiene exactamente UNA implementación.

Crear una interfaz ICreateProductHandler cuya única clase hija es CreateProductHandler no es desacoplamiento: es ceremonia. Es código que tienes que mantener, renombrar y navegar en el IDE sin recibir ningún beneficio a cambio.

¿Y la testabilidad?

La testabilidad no viene de tener una interfaz; viene de cómo recibe sus dependencias la clase. Como CreateProductHandler recibe todo por su constructor primario, en tus pruebas unitarias simplemente haces:

var handler = new CreateProductHandler(dbRealOInMemory, fakeDispatcher);
var result = await handler.Handle(request, CancellationToken.None);

¡No necesitas mockear la interfaz del handler porque estás testeando el handler mismo!

Dónde SÍ usamos interfaces

La regla nunca fue "no usar interfaces", sino "no usar interfaces sin una segunda implementación real". Las interfaces se reservan para las fronteras del sistema, donde genuinamente existen implementaciones alternativas:

TimeProvider (reloj real del sistema vs reloj congelado para tests).
IEventDispatcher (despachador in-process vs despachador de test o distribuido).
Pasarelas de pago (IStripeService vs FakePaymentGateway).
Envío de correos (SendGridClient vs NullEmailSender).

Registro automático por convención con Scrutor

Para no tener que registrar a mano cada handler en el contenedor de dependencias con services.AddScoped<CreateProductHandler>(), usamos la librería Scrutor para escanear el ensamblado al iniciar la aplicación.

En Composition/UseCaseRegistration.cs:

namespace VsaTemplate.Composition;

public static class UseCaseRegistration
{
    public static IServiceCollection AddUseCaseHandlers(this IServiceCollection services) =>
        services.Scan(scan => scan
            .FromAssemblyOf<Program>()
            .AddClasses(classes => classes.Where(t => 
                t is { IsPublic: true, IsAbstract: false } && t.Name.EndsWith("Handler")))
            .AsSelf()
            .WithScopedLifetime());
}

¿Qué hace esto?

Busca cualquier clase pública que termine en Handler.
La registra AsSelf() (su propio tipo concreto) con ciclo de vida Scoped.
Consecuencia: Cuando creas un nuevo caso de uso (ej. UpdateProductHandler), no tocas ningún archivo de configuración. El contenedor ya sabe resolverlo.

¿Por qué le dijimos adiós a MediatR?

Durante años, MediatR fue el estándar indiscutible en .NET para implementar el patrón Command/Query. Pero el contexto ha cambiado drásticamente:

    ERA ANTERIOR (Controllers + MediatR)
    HTTP Request ──► Controller ──► MediatR.Send ──► Pipeline ──► Handler
    (Mucha delegación innecesaria para terminar en el mismo método)

    ERA MODERNA (Minimal APIs + Endpoint Filters)
    HTTP Request ──► Minimal API Endpoint ──► Endpoint Filter ──► Handler
    (Directo, nativo, sin intermediarios ni reflexión costosa)

Minimal APIs resuelve el enrutamiento directamente al handler: En el mapeo de rutas simplemente inyectas el handler: (CreateProduct.Request req, CreateProductHandler handler) => handler.Handle(req). Minimal APIs resuelve el handler del contenedor y lo llama directo. No hay nada que "mediar".
Los cross-cutting concerns ahora son Endpoint Filters: El logging, la validación o las métricas que antes metías en IPipelineBehavior<TRequest, TResponse> ahora se manejan con los filtros nativos de ASP.NET Core (EndpointFilter).
Cambio de licenciamiento: A partir de 2025, MediatR adoptó un modelo de licencia comercial. Para qué pagar o preocuparte por licencias cuando el framework base de .NET ya te da todas las herramientas necesarias de forma más rápida y limpia.

Persistencia con EF Core: El "antipatrón" del repositorio genérico

Muchos proyectos de Clean Architecture meten una capa obligatoria de repositorios: IRepository<T>, IProductRepository, etc.

Pero recordemos un detalle técnico elemental:

Entity Framework Core ya implementa los patrones Unit of Work (DbContext) y Repository (DbSet<T>).

Crear un ProductRepository encima de EF Core solo para hacer:

public async Task<Product?> GetByIdAsync(Guid id) => await _context.Products.FindAsync(id);

es crear una abstracción con fuga (leaky abstraction). Pierdes la potencia de LINQ, la capacidad de hacer proyecciones directas (.Select()), paginación eficiente, AsNoTracking(), o splits queries.

En nuestra plantilla, los handlers consumen AppDbContext directamente:

var product = await db.Products
    .AsNoTracking()
    .Where(p => p.Id == id)
    .Select(p => new ProductDto(p.Id, p.Name, p.Price))
    .FirstOrDefaultAsync(ct);

Rápido, expresivo y con cero capas intermedias inútiles.

La configuración Fluent API vive junto a la entidad

Siguiendo nuestra pregunta guía: ¿Qué cambia junto?, si agregas una columna a Product, la configuración de base de datos cambia en el mismo commit.

Por eso, en vez de una carpeta lejana Infrastructure/Data/Configurations/, colocamos ProductConfiguration.cs dentro del slice: Features/Products/Domain/:

namespace VsaTemplate.Features.Products.Domain;

public class ProductConfiguration : IEntityTypeConfiguration<Product>
{
    public void Configure(EntityTypeBuilder<Product> builder)
    {
        builder.Property(p => p.Name).HasMaxLength(200);
        builder.Property(p => p.Price).HasPrecision(18, 2);
        builder.Property(p => p.RowVersion).IsConcurrencyToken();
    }
}

AppDbContext las descubre automáticamente con una sola línea en OnModelCreating:

modelBuilder.ApplyConfigurationsFromAssembly(typeof(Program).Assembly);

Pero... ¿por qué las migraciones están centralizadas en `Common`?

Aquí ocurre algo fascinante. Alguien podría pensar: "Si todo vive en el slice, ¿por qué no ponemos las migraciones dentro de Features/Products/Migrations?"

La respuesta es técnica: Entity Framework Core no permite partir las migraciones por carpeta o feature.

Cada migración es un cálculo diferencial del modelo completo de datos de la base, apoyado en un único ModelSnapshot lineal por DbContext. Si intentaras dividirlas por feature, corromperías la historia secuencial de la base de datos.

Por eso, las migraciones se generan centralizadas en Common/Persistence/Migrations/. VSA no es dogma: somos pragmáticos y respetamos la naturaleza de las herramientas que usamos.

Validación elegante: FluentValidation en un Endpoint Filter

¿Cómo validamos el request sin llenar el handler de ifs if (string.IsNullOrEmpty(request.Name))?

En la plantilla utilizamos un filtro de endpoint genérico: ValidationFilter.cs.

namespace VsaTemplate.Common.Endpoints;

public static class ValidationFilterExtensions
{
    public static RouteHandlerBuilder WithValidation<TRequest>(this RouteHandlerBuilder builder)
        where TRequest : class =>
        builder
            .AddEndpointFilter(async (context, next) =>
            {
                // Obtenemos el validador registrado para este tipo de Request
                var validator = context.HttpContext.RequestServices
                    .GetRequiredService<IValidator<TRequest>>();

                var request = context.Arguments.OfType<TRequest>().First();
                var result = await validator.ValidateAsync(request, context.HttpContext.RequestAborted);

                // Si la validación falla, corta la petición y retorna HTTP 400 Bad Request (ProblemDetails)
                return result.IsValid
                    ? await next(context)
                    : TypedResults.ValidationProblem(result.ToDictionary());
            })
            .ProducesValidationProblem(); // Documenta automáticamente el error 400 en OpenAPI
}

En el mapeo de la ruta en Endpoints.cs, solo agregas una extensión encadenada:

group.MapPost("/", (CreateProduct.Request request, CreateProductHandler handler, CancellationToken ct) 
    => handler.Handle(request, ct))
    .WithName(nameof(CreateProduct))
    .WithValidation<CreateProduct.Request>();

Las grandes ventajas de este enfoque:

El Handler es territorio sagrado: El handler sabe que si el código llegó a él, los datos ya son 100% válidos. No necesita manejar ValidationProblem ni ensuciarse con validaciones.
Respuesta estándar: Si falla, el cliente recibe automáticamente un RFC 9457 ProblemDetails estándar con el desglose de errores por propiedad.
Fail fast en desarrollo: Si usas .WithValidation<T>() pero olvidaste escribir la clase Validator, el contenedor falla inmediatamente con una excepción explícita (GetRequiredService), impidiendo que despliegues un endpoint con validaciones rotas.

Comunicación entre Slices: Eventos in-process

Nuestra Regla #1 de VSA dice:

«Un slice no usa los casos de uso ni los handlers de otro slice».

Pero surge un problema real: cuando se coloca una orden de compra en el slice Orders, necesitamos que el slice Notifications envíe un correo y registre un log. ¿Cómo lo hacemos sin que PlaceOrderHandler llame directamente a Notifications?

La respuesta: Eventos de dominio in-process.

Un Dispatcher propio de ~40 líneas

En lugar de instalar librerías pesadas, la plantilla incluye un dispatcher sencillo y directo en Common/Events/EventDispatcher.cs:

namespace VsaTemplate.Common.Events;

public class EventDispatcher(IServiceProvider services) : IEventDispatcher
{
    public async Task Publish<TEvent>(TEvent @event, CancellationToken ct = default)
        where TEvent : class
    {
        // Resuelve todos los handlers suscritos a TEvent en el scope actual
        foreach (var handler in services.GetServices<IEventHandler<TEvent>>())
        {
            await handler.Handle(@event, ct);
        }
    }
}

El contrato público vive en `Contracts/`

El slice emisor (Orders) define su evento en una subcarpeta pública: Features/Orders/Contracts/OrderPlaced.cs:

namespace VsaTemplate.Features.Orders.Contracts;

public record OrderPlaced(Guid OrderId, Guid ProductId, int Quantity, decimal Total);

Cuando se coloca la orden, PlaceOrderHandler simplemente publica el evento:

await eventDispatcher.Publish(new OrderPlaced(order.Id, product.Id, quantity, total), ct);

Y en el slice de notificaciones (Features/Notifications/OrderPlacedNotification.cs), escuchamos el evento:

public class OrderPlacedNotification(ILogger<OrderPlacedNotification> logger) 
    : IEventHandler<OrderPlaced>
{
    public Task Handle(OrderPlaced @event, CancellationToken ct)
    {
        logger.LogInformation("Nueva orden recibida: {OrderId}. Enviando confirmación...", @event.OrderId);
        return Task.CompletedTask;
    }
}

Orders no tiene la más remota idea de que Notifications existe. Están 100% desacoplados.

¿Cuándo migrar a Wolverine o MassTransit?

Este dispatcher in-process es ligero y comparte la misma transacción y memoria del request. Si el proceso del servidor se cae a la mitad, el evento en memoria se pierde.

Cuando necesites garantías transaccionales duras (Outbox Pattern), reintentos automáticos ante caídas o enviar mensajes a brokers externos (RabbitMQ, Kafka, Azure Service Bus), el salto natural y recomendado en el ecosistema .NET es Wolverine. Y lo mejor: como tus handlers ya son métodos limpios, migrar a Wolverine requiere mínimos cambios.

Resumen del flujo de un caso de uso

  HTTP POST /api/products
            │
            ▼
 ┌──────────────────────────────────────┐
 │       Endpoint Route Builder         │
 └──────────────────┬───────────────────┘
                    │
                    ▼
 ┌──────────────────────────────────────┐
 │ .WithValidation<CreateProduct.Req>() │ ──► ¿Inválido? ──► HTTP 400 ProblemDetails
 └──────────────────┬───────────────────┘
                    │ (Válido)
                    ▼
 ┌──────────────────────────────────────┐
 │        CreateProductHandler          │
 │  • Guarda en DbContext (EF Core)     │
 │  • Publica EventDispatcher           │
 └──────────────────┬───────────────────┘
                    │
                    ▼
          HTTP 201 Created (JSON)

Conclusión y lo que viene en la Parte 3

Hemos visto cómo un slice cobra vida:

Casos de uso compactos y altamente cohesivos.
Handlers concretos sin interfaces ficticias, registrados automáticamente por convención con Scrutor.
Persistencia directa con Entity Framework Core.
Validación automática desacoplada del negocio mediante Endpoint Filters.
Comunicación limpia entre slices mediante eventos in-process.

Pero falta la pieza más crítica de todas: la protección y el futuro.

¿Cómo testeamos estos slices sin caer en la pesadilla de mockear 20 llamadas a repositorios?
¿Cómo evitamos que un desarrollador distraído rompa las reglas y acople los slices entre sí?
¿Cómo compartimos estos modelos C# con el frontend en Angular/React sin desincronizarnos?
¿Y cómo escala esta arquitectura si el sistema crece a 50 o 100 slices?

Todo eso lo resolveremos en el cierre de la trilogía: Parte 3: Blindaje, Frontend y Evolución.

Código fuente de referencia

El código de todos los ejemplos proviene directamente de la plantilla:

👉 Repositorio en GitHub: betoramiz/vsa-template

¡Déja tu opinión en los comentarios! ¿Qué opinas de eliminar las interfaces en los handlers? ¿Prefieres eventos in-process o usar un mediador tradicional?

Deconstruyendo Clean Architecture: Por qué nos cansa y cómo Vertical Slice Architecture nos devuelve la paz en .NET (Parte 1)

Beto Ramirez — Sun, 27 Sep 2026 20:36:38 +0000

¿Alguna vez has tenido esa sensación de "estoy escribiendo demasiada burocracia" al crear un endpoint sencillo en .NET?

Imagina esta escena cotidiana: tu equipo necesita agregar un endpoint para registrar un producto. Una tabla sencilla con tres columnas: Id, Name y Price. Nada del otro mundo.

Abres tu solución y el viaje comienza:

Creas la entidad en MiApp.Domain.
Defines una interfaz en MiApp.Application.Contracts (ICreateProductUseCase o IProductRepository).
Creas un ProductDto, un CreateProductCommand y un mapper (o perfil de AutoMapper).
Implementas la interfaz en MiApp.Application o MiApp.Infrastructure.
Implementas el repositorio ProductRepository con un único método AddAsync.
Creas el controlador en MiApp.Api, inyectas la interfaz y conectas los cables.
Registras el servicio en el contenedor de Inyección de Dependencias.

Quince minutos después, tienes 7 archivos modificados o creados en 4 proyectos distintos para guardar una fila en una base de datos. Y lo peor de todo: esa interfaz ICreateProductService solo tiene —y tendrá por siempre— una sola implementación.

Si te sentiste identificado, bienvenido al club. Esto no es falta de ganas: es fatiga por arquitectura ceremonial.

En esta serie de 3 entregas exhaustivas, vamos a desarmar este problema y ver cómo construir una Web API en .NET con Vertical Slice Architecture (VSA) de forma pragmática, tomando como referencia una plantilla lista para producción construida con C# moderno y Minimal APIs.

El problema de Clean Architecture: El costo se paga el día uno

Clean Architecture, Onion Architecture o la arquitectura hexagonal son herramientas magníficas... cuando el problema que resuelven justifica su costo. El problema ocurre cuando las adoptamos por defecto como si fueran una ley grabada en piedra.

En una arquitectura por capas tradicional, el software se organiza por preocupaciones técnicas:

[ Capa de Presentación / API ]
             │
             ▼
[ Capa de Aplicación (Casos de uso / DTOs) ]
             │
             ▼
[ Capa de Dominio (Entidades / Lógica pura) ]
             ▲
             │
[ Capa de Infraestructura (EF Core / Repositorios) ]

Cada capa vive en un proyecto .csproj separado. Para cualquier cambio, tu mente y tu editor tienen que saltar de un proyecto a otro. Las cosas que cambian juntas están separadas por la fuerza.

Pero lo más peligroso es esto:

En Clean Architecture pagas el costo máximo de complejidad desde el día 1 para todos los casos de uso, incluso para los más triviales.

Un CRUD de lectura de 2 campos paga la misma ceremonia que un motor de pricing financiero hipercomplejo con reglas de negocio cambiantes.

¿Y si invertimos la fórmula?

La idea central: La complejidad se paga por slice

Aquí es donde entra Vertical Slice Architecture (VSA), popularizada por referentes como Jimmy Bogard (creador de MediatR) y refinada por Derek Comartin (CodeOpinion) y Milan Jovanović.

En VSA, la estructura del código no refleja la técnica (capas), sino las capacidades del negocio (features):

       CAPAS TRADICIONALES                   VERTICAL SLICE
     (División por técnica)               (División por negocio)

  ┌─────────────────────────┐          ┌──────────┐ ┌──────────┐
  │      Presentación       │          │          │ │          │
  ├─────────────────────────┤          │ Feature  │ │ Feature  │
  │       Aplicación        │   ──►    │ Products │ │  Orders  │
  ├─────────────────────────┤          │          │ │          │
  │         Dominio         │          │          │ │          │
  ├─────────────────────────┤          │          │ │          │
  │     Infraestructura     │          │          │ │          │
  └─────────────────────────┘          └──────────┘ └──────────┘

En lugar de rebanar el sistema de forma horizontal, lo cortamos en rebanadas verticales. Un slice atraviesa todo lo necesario para resolver ese caso de uso: desde la ruta HTTP hasta la consulta a la base de datos.

La premisa de oro es:

La complejidad se paga por slice, no por proyecto.

¿Un caso de uso es un simple reporte o un CRUD directo? Se resuelve en un único archivo, usando consultas directas sin ceremonias.
¿Otro caso de uso es crítico, tiene reglas complejas y requiere validación avanzada y eventos? Ese slice particular tendrá un modelo de dominio rico, validadores dedicados y más pruebas.

Y lo mejor: la complejidad de un caso de uso difícil no contamina al resto de la aplicación.

Las 5 reglas que sustituyen a la policía de capas

En Clean Architecture, la separación en múltiples proyectos .csproj existe para que el compilador nos impida hacer trampas (por ejemplo, que el dominio no referencie a la base de datos).

Al movernos a una arquitectura de vertical slices dentro de un solo proyecto Web API, eliminamos los muros físicos. Pero para que no se convierta en el temido "código espagueti", establecemos 5 reglas de oro explícitas:

Un slice no usa los casos de uso de otro slice. Lo público de un slice es únicamente su modelo de datos (Domain/, para consultas compartidas) y sus eventos (Contracts/). La lógica interna de un caso de uso es privada.
Nada entra a Common hasta que se repita al menos 3 veces. La abstracción prematura es la raíz de la complejidad innecesaria. No crees una clase base genérica porque "quizás la usemos luego". Si dos features hacen algo similar, permítete duplicar un poco de código. A la tercera repetición, se refactoriza a Common.
El archivo de endpoints se mantiene tonto. Solo mapea la ruta HTTP hacia el handler correspondiente. Cero lógica de negocio, cero consultas directas en el mapeo de rutas.
La complejidad es opt-in por slice. Validadores, modelos enriquecidos, manejo transaccional... se agregan únicamente donde el negocio lo exige.
Camino de crecimiento sin saltos dramáticos. Feature pequeño en una carpeta → Feature grande convertido en módulo → Monolito Modular → Microservicio (solo si realmente hace falta escalabilidad independiente).

Estructura de proyecto: Menos proyectos, más claridad

¿Cómo se ve esto en la vida real? En lugar de tener una solución con 5 proyectos .csproj, arrancamos con un solo proyecto Web API y su proyecto de tests correspondiente:

# Crear solución y proyectos
dotnet new slnx -n MiApp
dotnet new web -n MiApp -o src/MiApp
dotnet new xunit -n MiApp.Tests -o tests/MiApp.Tests

dotnet sln add src/MiApp tests/MiApp.Tests
dotnet add tests/MiApp.Tests reference src/MiApp

La estructura dentro de src/MiApp queda limpia, intuitiva y navegable:

src/MiApp/
├── Program.cs                    ← Composición de la app
├── Common/                       ← Infraestructura compartida real
│   ├── Endpoints/                ← Contratos base y filtros
│   ├── Persistence/              ← DbContext global y migraciones
│   └── ErrorHandling/            ← Manejo de errores RFC 9457
├── Composition/
│   └── UseCaseRegistration.cs    ← Registro automático por convención
└── Features/
    ├── Products/                 ← Slice de Productos
    │   ├── Endpoints.cs          ← Solo enrutamiento de este feature
    │   ├── CreateProduct.cs      ← Un caso de uso = un archivo
    │   ├── GetProducts.cs
    │   ├── GetProductById.cs
    │   ├── DeleteProduct.cs
    │   └── Domain/
    │       ├── Product.cs
    │       └── ProductConfiguration.cs
    └── Orders/                   ← Slice de Órdenes
        ├── Endpoints.cs
        ├── PlaceOrder.cs
        ├── GetOrderById.cs
        ├── Contracts/
        │   └── OrderPlaced.cs    ← Eventos públicos para otros slices
        └── Domain/
            └── Order.cs

Nota algo fundamental: cuando te asignen una tarea sobre "Productos", nunca sales de la carpeta Features/Products. No tienes que abrir 6 carpetas en el explorador de soluciones. Todo lo que cambia junto, vive junto.

Enrutamiento con Minimal APIs: Endpoints tontos y limpios

Hay quienes meten toda la definición de rutas, validación y lógica dentro del propio Program.cs. A los 5 endpoints, Program.cs se vuelve inleíble.

Nuestra decisión de diseño fue:

Separar las rutas de la lógica: Cada feature tiene un archivo Endpoints.cs. Funciona como la "tabla de contenidos" del slice.
Endpoints tontos: El endpoint solo recibe la petición HTTP y se la pasa al handler.

Observa cómo se ve Features/Products/Endpoints.cs:

namespace VsaTemplate.Features.Products;

public class Endpoints : IFeatureEndpoints
{
    public static void Map(IEndpointRouteBuilder app)
    {
        var group = app.MapGroup("/api/products")
            .WithTags("Products");

        group.MapPost("/", (CreateProduct.Request request, CreateProductHandler handler, CancellationToken ct) 
            => handler.Handle(request, ct))
            .WithName(nameof(CreateProduct))
            .WithValidation<CreateProduct.Request>();

        group.MapGet("/", (int? page, int? pageSize, GetProductsHandler handler, CancellationToken ct) 
            => handler.Handle(page, pageSize, ct))
            .WithName(nameof(GetProducts));

        group.MapGet("/{id:guid}", (Guid id, GetProductByIdHandler handler, CancellationToken ct) 
            => handler.Handle(id, ct))
            .WithName(nameof(GetProductById));

        group.MapDelete("/{id:guid}", (Guid id, DeleteProductHandler handler, CancellationToken ct) 
            => handler.Handle(id, ct))
            .WithName(nameof(DeleteProduct));
    }
}

¿Qué logramos con esto?

En 20 líneas de código entiendes todo lo que ofrece el módulo de productos.
Las rutas están agrupadas con prefijo /api/products y categorizadas para OpenAPI.
Cada endpoint delega inmediatamente en su *Handler.
.WithName(...) le da una identidad única a la operación (clave para el frontend, como veremos en la Parte 3).

Auto-descubrimiento de Endpoints: Olvídate de tocar Program.cs

Uno de los mayores dolores de cabeza en proyectos grandes es el archivo central de configuración. Cada vez que alguien crea un feature, tiene que tocar Program.cs para registrarlo. Si 3 programadores hacen esto al mismo tiempo en ramas distintas, prepárate para los conflictos de Git (merge conflicts).

Para resolver esto, implementamos un patrón de auto-descubrimiento.

Aprovechando las interfaces con métodos estáticos abstractos (static abstract) introducidas en C# 11, definimos un contrato muy simple en Common/Endpoints/IFeatureEndpoints.cs:

namespace VsaTemplate.Common.Endpoints;

public interface IFeatureEndpoints
{
    static abstract void Map(IEndpointRouteBuilder app);
}

Y luego, en Common/Endpoints/EndpointRegistration.cs, creamos un método de extensión que escanea el ensamblado al arrancar y mapea automáticamente todas las clases que implementen esta interfaz:

public static class EndpointRegistration
{
    public static IEndpointRouteBuilder MapFeatureEndpoints(this IEndpointRouteBuilder app)
    {
        var endpointTypes = typeof(Program).Assembly.GetTypes()
            .Where(t => t is { IsAbstract: false, IsInterface: false } 
                     && typeof(IFeatureEndpoints).IsAssignableFrom(t));

        foreach (var type in endpointTypes)
        {
            var mapMethod = type.GetMethod(
                nameof(IFeatureEndpoints.Map), 
                BindingFlags.Public | BindingFlags.Static);

            mapMethod?.Invoke(null, [app]);
        }

        return app;
    }
}

Ahora, en tu Program.cs, solo necesitas una sola línea:

var app = builder.Build();

// Registra todos los endpoints de todos los features automáticamente
app.MapFeatureEndpoints();

app.Run();

El resultado: Agregar un feature nuevo es tan simple como crear la carpeta Features/Clientes/, agregar su Endpoints.cs implementando IFeatureEndpoints, y listo. El sistema lo descubre al compilar. No tocas Program.cs para nada.

Conclusión y lo que viene

Hemos pasado de una maraña de capas horizontales a un esquema vertical donde:

Organizamos el código por capacidades de negocio, no por conceptos técnicos.
Eliminamos proyectos .csproj innecesarios y reducimos la fricción mental.
Definimos rutas limpias con Minimal APIs y las descubrimos automáticamente sin tocar archivos centrales.

Pero ahora viene la pregunta del millón:

¿Cómo se ve por dentro ese CreateProduct.cs?

¿Dónde quedaron las interfaces? ¿Cómo inyectamos las dependencias si no usamos ICreateProductHandler?

¿Y qué pasó con MediatR? ¿Cómo interactuamos con Entity Framework Core sin escribir una capa de repositorios?

Todo eso lo veremos en la Parte 2: Anatomía de un Slice en Producción, donde destriparemos el diseño de los Handlers, la validación elegante sin ensuciar el negocio, y la comunicación entre slices mediante eventos ligeros.

¿Quieres explorar el código completo?

Puedes clonar y probar la plantilla directamente desde el repositorio de GitHub:

👉 betoramiz/vsa-template

Cuéntame en los comentarios: ¿En tu equipo actual usan Clean Architecture tradicional? ¿Cuántos proyectos tiene tu solución .NET habitual? ¡Nos leemos abajo!

CoreDriven: Un Template de Arquitectura Limpia en .NET para Acelerar tu Desarrollo

Beto Ramirez — Sun, 10 Aug 2025 22:07:02 +0000

Para cualquier desarrollador de .NET, iniciar un nuevo proyecto implica una serie de decisiones cruciales sobre la arquitectura. ¿Cómo aseguramos que la aplicación sea mantenible, escalable y, sobre todo, fácil de probar? La Arquitectura Limpia (Clean Architecture) nos ofrece una solución robusta, y con el template CoreDriven, he querido llevar esa implementación un paso más allá.

Este post explora las características de Core-Driven, un template de proyecto en .NET Core diseñado para programadores que buscan una base sólida y moderna para sus aplicaciones.

El Fundamento: Arquitectura Limpia

CoreDriven se basa en los principios de la Arquitectura Limpia, garantizando una clara separación de responsabilidades. El dominio y la lógica de negocio (los casos de uso) están en el centro, sin dependencias de frameworks externos como Entity Framework o ASP.NET Core.

Esto se traduce en beneficios directos:

Independencia: Tu lógica de negocio no sabe nada sobre la base de datos, la UI o cualquier servicio externo.

Testabilidad: Probar las reglas de negocio se vuelve trivial, ya que no requieren un entorno web o una base de datos activa.

Mantenibilidad: Cambiar un detalle de infraestructura (como pasar de SQL Server a PostgreSQL) no afecta al corazón de tu aplicación.

Casos de Uso, una Sintaxis más Limpia

Una de las decisiones de diseño en CoreDriven es cómo se estructuran los casos de uso (Use Cases). En lugar de usar una sola clasepara multiples funcionalidades, hacemos uso de una clase para solamente una solan funcinalidad, esto hara que el caso de uso tenga una forma lógica y concisa.

Observa la diferencia. La implementación de un caso de uso se agrupa dentro de un solo archivo, mejorando la cohesión y la legibilidad.

Este enfoque no solo reduce el número de archivos, sino que también hace que la navegación y la comprensión del flujo de una feature sean mucho más intuitivas.

Ahora bien, en la capa de casos de uso podemos agruparlos con un nombre descriptivo que nos diga exactamente que es lo que el caso de uso resulve.
Por ejemplo, en un TodoList, el caso de uso de creacion puede contener los archivos de Creacion del Todo, el Request, Response y las validaciones.

Y asi podemos listar todos los casos de uso para la entidad Todo.

La agrepacion de todos los casos de uso correspondiente a Todo la haremos con record que contega todos los casos de uso y que ademas implmente la interfaz IUseCaseRepository.

Inyección de Dependencias Automática con Scrutor.

Configurar la inyección de dependencias puede ser tedioso. Registrar cada servicio y su interfaz (services.AddScoped()) en proyectos grandes consume tiempo y es propenso a errores.

Con este enfoque CorDriven camos a hacer uso de Scrutor, una pequeña pero potente librería que automatiza este proceso mediante el escaneo de ensamblados. Con unas pocas líneas de código, todos tus servicios, handlers y validadores de FluentValidation quedan registrados.

Vamos a definir dos interfaces que solo seran indicadores para que Scrutor sepa donde buscar.

La interfaz IUseCase y la interfaz IUseIUseCaseRepository

Ahora cada uno de nuestros casos de uso pueden hacer uso de la interfaz IUseCase y el record que agrupa a todos los use cases hara uso de la interfaz IUseCaseRepository.

Esto hara que la inyeccion de dependencias con Scrutor sea muy simple:

Pruebas Unitarias Simples y Confiables.

Gracias a la arquitectura desacoplada, probar nuestros casos de uso es increíblemente fácil. No necesitamos mocks complejos ni configuraciones aparatosas. La lógica de negocio está aislada y lista para ser validada.

La prueba es limpia, legible y se enfoca exclusivamente en la lógica del caso de uso, validando su comportamiento de forma aislada.

Si buscas una base sólida, moderna y bien estructurada para tu próximo proyecto en .NET, te invito a que le des una oportunidad a CoreDriven.

Visita el repositorio en GitHub: https://github.com/betoramiz/coredriven

¡Clónalo y empieza a construir!

Cualquier feedback, sugerencia o contribución es más que bienvenida. ¡Espero que este template te ayude a construir software increíble!

Separando la logica de la capa de negocios en casos de uso.

Beto Ramirez — Wed, 09 Apr 2025 20:39:35 +0000

En este post quiero explicar como se puede lograr una separacion entre a logica de la aplicacion o capa de reglas de negocio del resto de las capas de la arquitectura que estemos utilizando.

El codigo completo lo puedes encontrar Aqui

El problema.

He tenido la oportunidad de trabajar en distintos tipos de proyectos, algunos muy grandes, otros pequeños y otros de tamaño medio.

En mucho de ellos he visto la implementacion de la capa de logica de negocios donde se defina una interfaz que contiene la definicion de las acciones de de ese servicio.

Supongamos que tenemos una aplicacion que tiene la entidad cliente y en la capa donde vive nuestra logica de aplicacion tenemos una interfaz que define todas las acciones del cliente.

Algo como esto.

Dentro de esta interfaz podemos agregar cuantos metodos necesitemos y entre mas metodos agregemos, la clase que implemente dicha interfaz sera un mounstroo de muchisimas lineas de codigo dificil de leer. y de mantener.

Esto no esta mal perse, ya que tenemos una interfaz que despues podemos inyectar en la capa superior que seria la capa de presentacion, nos permite hacere referencia a una abstracion, nos permitira tener mas facilidad de hacer unit testing y en general seguimos principios solid.

Pero esto tambien es mejorable y aqui es donde viene una propuesta de solucion.

Solucion.

Partiendo la interfaz

En la imagen anterior, la interfaz IClient implementa el principio de Single Resposanbility.
Tenemos una interfaz que tiene muchos metodos de la logica de aplicacion pero aun podemos tener mayor granularidad.
En lugar de tener una unica interfaz, podemos separarla en partes y generar una clase para cada accion, es decir, una clase por cada metodo definido en la interfaz.

Cada una de estas clases hacen referencia a un case de uso enconcreto de nuestra capa de negocios y estan perfectamente separadas.

Ahora, estas clases no implementan ninguna interfaz. Lo cual no esta mal por que aun asi podemos seguid inyectando cada una de estas clases en .NET pero no es lo ideal ya que estariamos dependiendo de una clase concreta y no de una abstraccion.

Agregando IUseCase

Para solucionarlo vamos a crear una interfaz que la nombraremos IUseCase y cada una de nuestras clases podras implementar esta interfaz.

Ahora si, nuestro caso de uso ya puede ser inyectado de mejor manera en nuestro controlador y obtener el cliente por Id.

Convirtiendo el IUseCase en generico.

Bien, ahora con este diseño nos enfretamos a otro "problema". Y es que tenemos que crer una interfaz por cada caso de uso, definir los parametros que recibe y el tipo de la respuesta de cada metodo, ademas de eso el nombre que tendra el metodo que ejecutara la logica de aplicacion podria tener el nombre que sea.

Para solucionar estos inconvenientes haremos uso de los Generics de C# y vamos a convertir a nuestra interfac IUseCase en una interfaz generica que tenga como entrada un tipo y que tenga una salida.

Ademsa de todo esto, tambien vamos a definir otra interfaz IRequest que servira para marcar a los datos de entrada de nuesto Caso de uso.

Con este caso de uso generico ya podemos estandarizar el nombre del metodo que ejecutara la logica de negocio en cada caso de uso, ademas, con la interfaz IRequest definimos que cada caso de uso tiene una entrada y genera una salida.

La implementacion de el caso de uso de obtener un cliente por Id quedaria de la siguiente manera:

Con esto, no necesitamos crear una interfaz para cada caso de uso, ahora estamos reutilizando una unica interfaz generica que nos ayudara a implementar la logica de negocio.

Y para hacer uso del case de uso tendriams que inyectar la interface IUseCase de la siguiente manera:

Hasta aqui tenemos una separacion de la logica de negocios de nuestro controller y ademas cada caso de uso esta en una clase separada lo que hace que queca caso de uso tenga una resposabilidad unica.

Seguimos manteniendo una inversion de control mediante la inyeccion de dependencias y segumos mantiendo la testeabilidad de la capa de negocios.

Despachador de Casos de uso.

Ok, considero que la implementacinon hasta este punto esta bien.

Si la logica de negocio empieza a crecer en numero de casos de uso, entonces nos tocara injectar un monton de estos en el contolador, no es un lio pero quiza el codigo no se vea tan "limpio" con eso.

Entonces, que tal que agregamos un despachador de casos de uso, es decir, una capa extra que internamente resuelva cual es el caso de uso que tiene que utilizar dependiendo de el request y el response:

Esta seria la implementacion de nuestro use case dispatcher.

Internamente hace uso del Service Provider de .net para poder entregarnos el caso de uso correcto.

Ademas, podemos loguear errores cuando se ejecute el metodo ExecuteAsync de cada caso de uso.

Y la implementacion en cada Controller seria algo asi: