Introducción a la clase
En la clase anterior vimos una visión general de Clean Architecture, sus principios y estructura. Ahora profundizaremos en cada una de sus capas, entendiendo su propósito, responsabilidades y cómo interactúan entre sí.
¿Qué obtendrás de esta clase?
- Comprenderás la función de cada capa en Clean Architecture.
- Aprenderás cómo organizar correctamente un proyecto en C#.
- Verás ejemplos prácticos para cada capa.
- Conocerás las mejores prácticas para implementar esta arquitectura de manera efectiva.
Las cuatro capas de Clean Architecture
Clean Architecture se organiza en capas concéntricas, donde cada una tiene responsabilidades específicas.
1. Capa de Dominio (Entities)
Propósito: Representar el corazón del negocio, definiendo las reglas y conceptos principales de la aplicación.
- Solo contiene lógica de negocio.
- No debe depender de frameworks, bases de datos o UI.
- Incluye Entidades, Value Objects y Agregados.
Ejemplo en C#: Entidad «Pedido»
public class Pedido
{
public int Id { get; private set; }
public string Cliente { get; private set; }
public decimal Total { get; private set; }
public Pedido(int id, string cliente, decimal total)
{
Id = id;
Cliente = cliente;
Total = total;
}
public void AplicarDescuento(decimal porcentaje)
{
Total -= Total * (porcentaje / 100);
}
}
2. Capa de Aplicación (Use Cases)
Propósito: Implementar la lógica de aplicación y coordinar el flujo de datos entre la capa de dominio y el mundo exterior.
- Contiene Casos de Uso que representan acciones específicas de la aplicación.
- No debe contener lógica de negocio, solo la orquestación de entidades.
- Define interfaces para los servicios externos (bases de datos, APIs, etc.).
Ejemplo en C#: Caso de uso «CrearPedidoUseCase»
public class CrearPedidoUseCase
{
private readonly IPedidoRepository _repository;
public CrearPedidoUseCase(IPedidoRepository repository)
{
_repository = repository;
}
public void Ejecutar(Pedido pedido)
{
// Regla de negocio aplicada en la capa de dominio
if (pedido.Total > 100)
pedido.AplicarDescuento(10);
_repository.Guardar(pedido);
}
}
Interfaz del Repositorio (Definida en la Capa de Aplicación)
public interface IPedidoRepository
{
void Guardar(Pedido pedido);
}
3. Capa de Infraestructura (Persistence, Adapters)
Propósito: Implementar los detalles técnicos de la aplicación, como persistencia de datos, acceso a APIs externas y configuración de frameworks.
- No contiene lógica de negocio.
- Implementa las interfaces definidas en la Capa de Aplicación.
- Puede cambiar sin afectar el dominio ni los casos de uso.
Ejemplo en C#: Implementación del Repositorio en Infraestructura
public class PedidoRepository : IPedidoRepository
{
public void Guardar(Pedido pedido)
{
Console.WriteLine($"Pedido {pedido.Id} guardado en la base de datos.");
}
}
4. Capa de Presentación (UI, API, CLI)
Propósito: Manejar la interacción con el usuario o con otros sistemas, como API REST, interfaces gráficas o líneas de comando.
- No contiene lógica de negocio ni reglas de aplicación.
- Solo se encarga de recibir las solicitudes y llamar a los casos de uso adecuados.
Ejemplo en C#: Controlador de API
[ApiController]
[Route("api/pedidos")]
public class PedidoController : ControllerBase
{
private readonly CrearPedidoUseCase _crearPedidoUseCase;
public PedidoController(CrearPedidoUseCase crearPedidoUseCase)
{
_crearPedidoUseCase = crearPedidoUseCase;
}
[HttpPost]
public IActionResult CrearPedido([FromBody] Pedido pedido)
{
_crearPedidoUseCase.Ejecutar(pedido);
return Ok("Pedido creado exitosamente");
}
}
Interacción entre capas en Clean Architecture
| Capa | Responsabilidad principal | Ejemplo en C# |
|---|---|---|
| Dominio (Entities) | Modelar reglas de negocio y datos fundamentales. | Entidad Pedido |
| Aplicación (Use Cases) | Orquestar la lógica de la aplicación. | CrearPedidoUseCase |
| Infraestructura (Persistence, Adapters) | Implementar detalles técnicos como DB o servicios externos. | PedidoRepository |
| Presentación (UI, API, CLI) | Manejar la comunicación con usuarios o sistemas. | PedidoController |
Ventajas de aplicar Clean Architecture con capas bien definidas
- Separación clara de responsabilidades.
- Facilita cambios en infraestructura sin afectar la lógica de negocio.
- Código modular y reutilizable.
- Mejor organización y facilidad para escribir pruebas unitarias.
Errores comunes al implementar Cean Architecture
- Lógica de negocio en la capa de Presentación → Solución: La lógica debe estar en la capa de Dominio o Aplicación.
- Dependencia directa de la base de datos en la capa de Aplicación → Solución: Usar interfaces para abstraer la infraestructura.
- Acoplamiento entre capas → Solución: Seguir el flujo de dependencias correctamente.
Cuestionario de Autoevaluación
- ¿Cuál es la responsabilidad principal de la capa de Dominio en Clean Architecture?
- ¿Qué diferencia hay entre la capa de Aplicación y la capa de Dominio?
- ¿Por qué la capa de Infraestructura no debe contener lógica de negocio?
- ¿Cuál es el propósito de definir interfaces en la Capa de Aplicación?
- ¿Cómo afecta Clean Architecture la mantenibilidad y escalabilidad del código?
Resumen de la Clase
- Clean Architecture se divide en cuatro capas: Dominio, Aplicación, Infraestructura y Presentación.
- Cada capa tiene una responsabilidad específica y no debe depender de detalles de implementación.
- Las interfaces en la capa de Aplicación permiten abstraer la infraestructura y facilitar cambios en la tecnología.
- Evitar dependencias directas entre capas ayuda a mantener el código desacoplado y modular.
Próximo paso
En la siguiente clase veremos cómo integrar DDD en Clean Architecture, combinando ambos enfoques para construir aplicaciones más robustas y bien organizadas.
