Clean Architecture en .NET 8
Implementación de arquitectura desacoplada centrada en el Dominio.
Esta implementación sigue el patrón de Onion Architecture, donde la lógica de negocio es el núcleo y las dependencias apuntan hacia adentro. Esto permite que el sistema sea independiente de la base de datos, del framework y de agentes externos, facilitando las pruebas unitarias y el mantenimiento a largo plazo.
1. DOMAIN
Entidades, Excepciones, Interfaces de Repositorio.
2. APPLICATION
Casos de Uso (Commands/Queries), DTOs, Mappers.
3. INFRASTRUCTURE
Persistencia (EF Core), Mailer, Servicios Externos.
4. PRESENTATION
WebAPI, Controllers o Minimal APIs.
En la carpeta Application/Interfaces, defino los contratos (ej. IOrderRepository.cs) en lugar de usar clases abstractas por las siguientes razones:
- Inversión de Dependencias: El dominio no depende de la base de datos. La implementación real (
OrderRepositoryInMemory.cs) reside en Infrastructure. - Flexibilidad de Testing: Al usar interfaces puras, facilito la creación de Mocks para pruebas unitarias sin la sobrecarga de una clase base.
- Cumplimiento de SOLID: Mantengo el principio de segregación de interfaces, permitiendo que cada servicio solo dependa de los métodos que realmente utiliza.
Manejo Genérico de Datos (Response.cs)
Como se observa en Application/Common, utilizo la clase Response.cs para envolver todas las salidas de la API. Esto garantiza que el cliente siempre reciba una estructura predecible (Success, Message, Errors, Data), facilitando el manejo de excepciones global.
Uso de AutoMapper y DTOs
En las carpetas DTOs y Mappings , gestiono la transformación de entidades de dominio (como Order.cs en ValueObjects ) hacia objetos de transferencia. Esto evita exponer la lógica interna y protege la integridad de los datos.
Estructura del Proyecto
SOLID Compliant- 📁 cleanArchitecture
Selecciona un archivo para ver su contenido...