DEV Community: Beto Ramirez

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: