Características y Beneficios de la Arquitectura Limpia

Clase 3 de 24 • Curso de Arquitecturas Limpias para Desarrollo de Software

Resumen

¿Qué son las arquitecturas limpias?

Las arquitecturas limpias son un enfoque estructural en el desarrollo de software que busca mantener la lógica de negocio (o dominio) independiente de las variaciones tecnológicas externas. La clara separación entre el dominio del negocio y los elementos externos es esencial, permitiendo que el sistema evolucione sin estar atado a tecnologías específicas. Pero, ¿qué caracteriza específicamente a una arquitectura limpia?

¿Por qué el dominio es el núcleo de las arquitecturas limpias?

El dominio es el corazón del sistema en una arquitectura limpia. Se refiere al conjunto de reglas y lógica de negocio que definen el funcionamiento y propósito de la aplicación.

En una aplicación de supermercado, por ejemplo, el dominio incluiría la gestión del inventario y el cálculo de descuentos.
En redes sociales, podría implicar la publicación de mensajes y la gestión de anuncios.
En un sistema de recursos humanos, abarcaría el cálculo de seguridad social y la gestión de permisos.

El dominio debe existir independientemente de la aplicación tecnológica, ya que es la esencia de por qué se construye el sistema.

¿Cómo se define lo que es un elemento externo en una arquitectura limpia?

Los elementos externos son componentes que no deberían influir en la organización del dominio. En arquitecturas limpias, se consideran externos:

Interfaces gráficas: No afectan la lógica de negocio; son solo una forma de presentación.
Bases de datos: Aunque vitales, son simplemente repositorios de información que pueden cambiar sin impactar el dominio.
Sistemas de terceros: Incluyen integraciones con software externo, como sistemas contables o redes sociales.
Frameworks: Herramientas de desarrollo como Angular, Django o .NET, aunque útiles, son externas y la lógica de negocio no debe depender de ellas.

La lógica de negocio debe estar libre de dependencias de estos elementos para asegurar flexibilidad y escalabilidad.

¿Qué significa que las dependencias se invierten en arquitecturas limpias?

La inversión de las dependencias es un principio clave en las arquitecturas limpias. Tradicionalmente, en una arquitectura de tres capas, las dependencias fluyen desde la capa de presentación hasta la capa de acceso a datos. Aquí:

Presentación → Depende del dominio.
Dominio → Depende del acceso a datos.

En una arquitectura limpia, esto se invierte:

El dominio no depende del acceso a datos; en cambio, el acceso a datos depende del dominio. Esto permite que la lógica de negocio se mantenga aislada y no se vea afectada por cambios en las tecnologías de almacenamiento.

¿Cómo facilitan las arquitecturas limpias la testabilidad?

La testabilidad es uno de los mayores beneficios de las arquitecturas limpias. Al separar el dominio de los elementos externos, las pruebas se pueden realizar aislando el dominio de otras dependencias:

Las pruebas se pueden ejecutar sin tener que configurar bases de datos u otros servicios externos.
Se pueden utilizar técnicas como mocking para simular componentes externos y verificar la lógica de negocio en diversas condiciones.

Esto simplifica el proceso de verificación y asegura que la lógica permanece robusta y sin impacto por cambios externos.

La capacidad de realizar pruebas más efectivas aumenta la confianza en el sistema y reduce los riesgos en el desarrollo. Así, las arquitecturas limpias no solo aseguran flexibilidad a largo plazo, sino que también optimizan la calidad del software desde sus bases.

carlos quintero

student•

Caracteristicas fundamentales en una arquitectura limpia.

segun el video menciono las cuatro caracteristicas:

1. Dominio como elemento central: En una arquitectura limpia, el dominio y la lógica de negocio son el corazón de la aplicación. Esto significa que todas las funcionalidades de la aplicación giran en torno a las reglas de negocio, que se encuentran en el centro de la arquitectura. Esto permite a los desarrolladores enfocarse en las reglas de negocio, que son las partes más críticas y valiosas de la aplicación

2. El dominio no depende de elementos externos. el término “dominio” generalmente se refiere a la lógica de negocio de la aplicación, que son las reglas y comportamientos que definen cómo opera tu aplicación o sistema.

Cuando se dice que “El dominio no depende de elementos externos”, significa que la lógica de negocio de la aplicación no debe depender de detalles de infraestructura como la base de datos, la interfaz de usuario, los servicios de red, entre otros.

Se podría cambiar la base de datos de MySQL a PostgreSQL, cambiar la interfaz de usuario de una interfaz gráfica a una interfaz de línea de comandos, o cambiar tu protocolo de red de HTTP a WebSocket, y ninguna de estas modificaciones debería requerir que cambies la lógica de negocio de tu aplicación.

3. Las dependencias se invierten: las dependencias inversas permiten que el código sea más modular y más fácil de mantener y desarrollar. La lógica de negocio no depende directamente de las implementaciones de base de datos o de otros servicios. En su lugar, estos servicios se conectan a la lógica de negocio a través de interfaces o abstracciones, lo que facilita el cambio de una implementación por otra sin afectar la lógica de negocio.

4. Facilitan las pruebas (Testability): Dado que la lógica de negocio no está entrelazada con la lógica de la infraestructura (como la UI, la base de datos, etc.), es más fácil de probar. se pueden crear pruebas para la lógica de negocio sin tener que preocuparte por los detalles de la implementación de la infraestructura.

Alexander Cevallos

student•

Características comunes:

Dominio como elemento central.
El dominio no depende de elementos externos.
Las dependencias se invierten.
Facilitan las pruebas (Testability).

HARLIN ACERO ACERO

student•

El dominio es el eje central del software. Por dominio se enciente la razón de ser del negocio, estas reglas son independientes de los componentes externos.
El dominio no depende de componentes externos. La lógica del negocio es independiente de otros factores.
Inversión de dependencias: A diferencia de las arquitecturas tradicionales, el dominio es completamente independiente y se basta por si mismo.
El dominio facilita el testeo, dado que no depende de nada.

Juan Carlos Aguilar Herrera

student•

Las Arquitecturas limpias, muy bueno implementarla en proyectos nuevos,ya en proyectos que tienen un alto acoplamiento si hay que mirar bien que tanto y hasta donde vale la pena invertirle recursos y tiempo para hacerlo.

Juan Jose Sepulveda Calderon

student•

Me estoy dando cuenta que no sé qué significa la lógica de negocio 😅

Platzi Team

student•

La "lógica de negocio" se refiere a las reglas y procesos específicos que gobiernan cómo una aplicación o sistema cumple con los objetivos y las necesidades de una organización o empresa.

Lancelot Fierro

student•

Caracteristicas de las arquitecturas limpias

Las arquitecturas limpias se diferencían de las arquitecturas normales al aplicar las siguientes caracteristicas:

El corazón de las arquitecturas limpias, son las reglas del negocio.

En las arquitecturas limpias, dividimos las capas de forma que el dominio (es decir, las reglas del negocio, las funciones mas escenciales para que un negocio funcione) son el centro de la arquitectura y lo más importante. Sobre el dominio se construyen los demás sistemas que agregan valor al negocio, pero no son necesariamente escenciales. Aún así, los demás sistemas dependen de el dominio. Eso nos lleva a la característica 2:

El dominio no depende de elementos externos.

¿Que es un elemento externo? Por ejemplo, una interfaz gráfica, una base de datos, o sistemas de terceros. Al dieseñar arquitecturas limpias, los dominios no deben depender de ninguno de estos elementos, sino al contrario, la base de datos, servicios o interfaces gráficas deben depender de el dominio. Los frameworks también cuentan como elementos externos, de forma que la lógica de negocio no deberia depender de frameworks.

Las dependencias se invierten

Esto quiere decir que en una arquitectura limpia existen dos tipos de capas. El dominio, y la capa externa, de forma que en el dominio está toda la lógica del negocio y el resto de los elementos forman parte de la capa externa.

Facilitan las pruebas

Como el dominio no depende de nada externo, es mucho más fácil hacer pruebas unitarias

Víctor Rolack

student•

Característica 1: Dominio como elemento central

Toda arquitectura limpia gira en torno a un dominio.

El dominio es la razón de ser del sistema

El dominio existe o no exista la aplicación. Todo lo que es el core del negocio clasifica como dominio. Por ejemplo, tenemos un supermercado que quiere hacer su app, parte del dominio serían la funcionalidad de calcular descuentos o verificar inventario.

Son características que existen estén o no estén las aplicaciones.

Característica 2: El dominio no depende de elementos externos

¿Qué son los elementos externos en una aplicación limpia?

Las interfaces gráficas no deberían de afectar a nuestro dominio
Las bases de datos. Es un repositorio de información, no significa que puede cambiar con el tiempo o incluso decidir que no exista, porque querría decir que el negocio depende de esto.
Sistemas de terceros. Por ejemplo, integraciones con red social. No son indispensables.
Frameworks. Angular, React, Django, todos estos son considerados frameworks. Nuestra lógica de negocio no debe depender de estos.

Característica 3: Las dependencias se invierten

Vemos un contraste entre la arquitectura limpia y la de tres capas. Vemos que en la segunda hay una gran dependencia entre capas, presentación depende de dominio y dominio de acceso a datos.

En la primera esto cambio, la dependencia se invierte, el dominio ya no depende de acceso a datos sino que el acceso a datos va a depender del dominio.

![[Captura de pantalla 2023-09-18 a la(s) 21.43.11.png|300]]![[Captura de pantalla 2023-09-18 a la(s) 21.43.48.png|300]]

Característica 4: Facilitan las pruebas (testability)

Que tengamos separado el dominio de la capa externa, esa encapsulación justamente facilita la creación de pruebas al dominio, por ejemplo, puedo hacer pruebas al dominio sin tener la necesidad de configurar la capa externa.

Sergio Ramirez

student•

Lo que no entiendo es si el dominio esta hablando de la lógica de negocios y de ser así esto se debe programar en algún lenguaje de programación, pero regularmente se programa bajo un framework y al hacer esto en realidad el dominio si va depender de un framework, o no se si el dominio se refiere a las historias de usuario algo más como el requerimiento, esta parte es la que no entiendo.

Manuel Zapata

teacher•

Algo que buscamos con una arquitectura limpia es no poner la lógica de negocio bajo un framework. Por ejemplo, en vez de poner la lógica en un controlador de Spring Boot o ASP .NET MVC, lo que hacemos es ponerla en una clase aparte que no dependa del framework.

Carlos Arturo Pimentel

student•

Manuel, una arquitectura de un monolito modular podría conseguirse utlizando un patrón de arquitectura limpia, o estaría mejor ajustarla a un patrón modularizado como el de sección vertical (Vertical Slice) ?

Manuel Zapata

teacher•

Buena pregunta, Carlos!

Una arquitectura limpia no te garantiza que tu sistema sea un monolito modular.

Sin haber estudiado bien los vertical slices, parece que este concepto es muy similar al del monolito modular.

Para quienes deseen conocer un poco más sobre monolitos modulares, les recomiendo este video de mi canal.

Carlos Arturo Pimentel

student•

Hola Manuel, quisiera conocer tu opinión sobre las arquitecturas limpias en términos de su performance, será que estás afectan negativamente el rendimiento de la aplicación como dicen algunos desarrolladores?

Manuel Zapata

teacher•

¿Podrías contarme lo que dicen algunos devs sobre el performance de estas arquitecturas?

En mi experiencia, las arquitecturas limpias no tienen un impacto significativo en el performance, ya que la forma como se organizan no implican que el sistema sea más lento.

William Schnaider Torres Bermon

student•

Si bien es cierto que las arquitecturas limpias pueden agregar una capa adicional de abstracción y complejidad, esto no necesariamente resulta en un rendimiento inferior. De hecho, una arquitectura limpia bien implementada puede ayudar a mejorar el rendimiento al permitir una mejor organización del código y una separación clara de las responsabilidades.

Royer Guerrero Pinilla

student•

Básicamente el Dominio es el eje central de las aplicaciones realizadas en arquitecturas limpias. El dominio son las reglas y lógica del negocio dichas reglas deben ser agnósticas de componentes externos (Bases de datos, Frameworks, Sistemas de terceros). Un ejemplo con la lógica de airbnb es que encontramos por ejemplo Reservas dichas reservas pueden tener ciertos atributos por ejemplo las persona que genera la reserva, el lugar asociado a la reserva, la cantidad de personas que asistirán a la reserva, etc... Pero también puede tener ciertas reglas como que las personas que asistan no supere el nivel que pueden tener el lugar o que por ejemplo que esa reserva no haga conflicto con otras reservas.

Ejemplo del objecto de dominio de reservas

Este podría tener por ejemplo algunas reglas de negocio como la de no hacer overbooking

Disclaimer este codigo puede tener typos 🙈

LEONARD CUENCA

student•

Clase 3: Características comunes de arquitecturas limpias

Características

El Dominio como elemento central -> Son los elementos que hacen el core del negocio.

En una arquitectura limpia, el dominio y la lógica de negocio son el corazón de la aplicación. 

Esto significa que todas las funcionalidades de la aplicación giran en torno a las reglas de negocio, que se 
encuentran en el centro de la arquitectura. 

Esto permite a los desarrolladores enfocarse en las reglas de negocio, que son las partes más críticas y valiosas de la aplicación

El dominio no depende de elementos externos. -> Consideramos elementos externos las interfaces y la base de datos ya que no afectan a nuestro dominio.

Generalmente se refiere a la lógica de negocio de la aplicación, que son las reglas y comportamientos que definen cómo opera tu aplicación o sistema.

Cuando se dice que “El dominio no depende de elementos externos”, significa que la lógica de negocio de la aplicación no debe depender de detalles de infraestructura 
como la base de datos, la interfaz de usuario, los servicios de red, entre otros.

Se podría cambiar la base de datos de MySQL a PostgreSQL, cambiar la interfaz de usuario de una interfaz gráfica a una interfaz de línea de comandos, 
o cambiar tu protocolo de red de HTTP a WebSocket, y ninguna de estas modificaciones debería requerir que cambies la lógica de negocio de tu aplicación.

Las dependencias se invierten -> Esto quiere decir que la capa mas externa va depender del dominio, aquí hay que imaginare que las capas con círculos y cada circulo exterior va depender del círculo mas interno que este es el dominio.

 las dependencias inversas permiten que el código sea más modular y más fácil de mantener y desarrollar. 
 La lógica de negocio no depende directamente de las implementaciones de base de datos o de otros servicios. 
 En su lugar, estos servicios se conectan a la lógica de negocio a través de interfaces o abstracciones, lo que facilita el 
 cambio de una implementación por otra sin afectar la lógica de negocio.

Facilitan las pruebas (Testability). -> Al tener el dominio separada de la capa externa nos permite aislar y realizar testing mas eficiente

Dado que la lógica de negocio no está entrelazada con la lógica de la infraestructura 
(como la UI, la base de datos, etc.), es más fácil de probar. 
se pueden crear pruebas para la lógica de negocio sin tener que preocuparte por los detalles de la implementación de la infraestructura.

Daniel Pérez

student•

Es decir, manteniendo una base de datos fuera de lógica de negocio me impediría tener una implementación de store procedures?

Juan Antonio Aramburo Pasapera

student•

Nope. La filosofía de las arquitecturas limpias te permitirían incluso cambiar la base de datos sin tener que reescribir todo. Tener stored procedures dificultaría eso.

Eric Castellón Blanco

student•

Mas o menos. Lo correcto, a mi parecer, es que la lógica de negocios no viva en stored procedures. Si estas tratando con código legacy cambia el asunto. Pero si estas arrancando de cero lo ideal sería que no. De inicio la base de datos debería ser pensada solo para guardar datos. Aclaro, en el inicio.

Andre Huaman Yovera

student•

🏗️ Ejemplo Práctico: Arquitectura Limpia en VetCarePro

🎯 El Dominio - El Corazón del Sistema

El Dominio es donde viven las reglas de negocio más importantes. Es como el "cerebro" de la aplicación veterinaria:

// �� VETCAREPRO DOMAIN - Las reglas de negocio

// 1. ENTIDADES (Los objetos principales del negocio)

public class Mascota : BaseEntity

{

public string Nombre { get; private set; }

public TipoMascota Tipo { get; private set; }

public decimal Peso { get; private set; }

public DateTime FechaNacimiento { get; private set; }

// 📋 REGLAS DE NEGOCIO - Aquí está la lógica importante

public int EdadEnAnios => DateTime.Today.Year - FechaNacimiento.Year;

public bool PuedeTenerVacuna()

{

// 🧠 REGLA: Solo mascotas mayores de 2 meses pueden vacunarse

var edadEnMeses = (DateTime.Today - FechaNacimiento).Days / 30;

return edadEnMeses >= 2;

}

public void ActualizarPeso(decimal nuevoPeso)

{

// 🧠 REGLA: El peso debe ser positivo y menor a 500kg

if (nuevoPeso <= 0 || nuevoPeso > 500)

throw new ArgumentException("Peso inválido");

Peso = nuevoPeso;

}

// 2. VALUE OBJECTS (Conceptos del negocio)

public class Dinero

{

public decimal Monto { get; private set; }

public string Moneda { get; private set; }

public Dinero(decimal monto, string moneda = "PEN")

{

if (monto < 0) throw new ArgumentException("El dinero no puede ser negativo");

Monto = monto;

Moneda = moneda;

}

// 🧠 REGLA: Cálculo de descuentos

public Dinero AplicarDescuento(decimal porcentaje)

{

var descuento = Monto * (porcentaje / 100);

return new Dinero(Monto - descuento, Moneda);

}

// 3. SERVICIOS DE DOMINIO (Lógica compleja de negocio)

public class CalculadoraPreciosVenta

{

public Dinero CalcularPrecioFinal(Dinero precioBase, decimal ivaPorcentaje = 19)

{

// 🧠 REGLA: Aplicar IVA del 19% (Perú)

var iva = precioBase.Monto * (ivaPorcentaje / 100);

return new Dinero(precioBase.Monto + iva, precioBase.Moneda);

}

�� Puntos Clave del Dominio:

✅ No depende de nada externo (ni bases de datos, ni frameworks)
✅ Contiene las reglas de negocio más importantes
✅ Es puro C# - sin dependencias de .NET específicas
✅ Fácil de testear - sin configuraciones externas

⚡ Capa de Aplicación - El Orquestador

La Aplicación coordina las operaciones y conecta el dominio con el mundo exterior:

// 🚀 VETCAREPRO APPLICATION - Coordinación y orquestación

// 1. COMMANDS (Operaciones que cambian el estado)

public record CreateMascotaCommand(

string Nombre,

TipoMascota Tipo,

string Raza,

SexoMascota Sexo,

DateTime FechaNacimiento,

decimal Peso,

string Color,

Guid PropietarioId,

string? Observaciones

);

// 2. HANDLERS (Ejecutan las operaciones)

public class CreateMascotaHandler : IRequestHandler<CreateMascotaCommand, Result<Guid>>

{

private readonly IMascotaRepository _mascotaRepository;

private readonly IPropietarioRepository _propietarioRepository;

public async Task<Result<Guid>> Handle(CreateMascotaCommand request, CancellationToken cancellationToken)

{

// 🔍 1. VALIDAR (usar el dominio)

var mascota = Mascota.Create(

request.Nombre,

request.Tipo,

request.Raza,

request.Sexo,

request.FechaNacimiento,

request.Peso,

request.Color,

request.Observaciones

);

// 🔍 2. VERIFICAR REGLAS DE NEGOCIO

var propietario = await _propietarioRepository.GetByIdAsync(request.PropietarioId);

if (propietario == null)

return Result.Failure<Guid>("Propietario no encontrado");

// 💾 3. GUARDAR (usar infraestructura)

await _mascotaRepository.AddAsync(mascota);

return Result.Success(mascota.Id);

}

// 3. QUERIES (Operaciones de consulta)

public record GetMascotasByPropietarioQuery(Guid PropietarioId);

public class GetMascotasByPropietarioHandler : IRequestHandler<GetMascotasByPropietarioQuery, List<MascotaDto>>

{

private readonly IMascotaRepository _mascotaRepository;

private readonly IMapper _mapper;

public async Task<List<MascotaDto>> Handle(GetMascotasByPropietarioQuery request, CancellationToken cancellationToken)

{

var mascotas = await _mascotaRepository.GetByPropietarioIdAsync(request.PropietarioId);

return _mapper.Map<List<MascotaDto>>(mascotas);

}

🔑 Puntos Clave de la Aplicación:

✅ Coordina entre dominio e infraestructura
✅ No contiene lógica de negocio (esa va en el dominio)
✅ Maneja validaciones, mapeos y orquestación
✅ Usa MediatR para desacoplar comandos y queries

🗄️ Capa de Infraestructura - El Almacén

La Infraestructura se encarga de persistir datos y conectar con sistemas externos:

// �� VETCAREPRO INFRASTRUCTURE - Persistencia y sistemas externos

// 1. REPOSITORIOS (Implementan las interfaces del dominio)

public class MascotaRepository : IMascotaRepository

{

private readonly ApplicationDbContext _context;

public async Task<Mascota?> GetByIdAsync(Guid id)

{

// 🗄️ CONVERTIR de Entidad EF a Entidad de Dominio

var mascotaEntity = await _context.Mascotas

.Include(m => m.Propietario)

.FirstOrDefaultAsync(m => m.Id == id);

if (mascotaEntity == null) return null;

// 🔄 MAPEO: EF Entity → Domain Entity

return Mascota.Create(

mascotaEntity.Nombre,

mascotaEntity.Tipo,

mascotaEntity.Raza,

mascotaEntity.Sexo,

mascotaEntity.FechaNacimiento,

mascotaEntity.Peso,

mascotaEntity.Color,

mascotaEntity.Observaciones

);

}

public async Task AddAsync(Mascota mascota)

{

// �� MAPEO: Domain Entity → EF Entity

var mascotaEntity = new MascotaEntity

{

Id = mascota.Id,

Nombre = mascota.Nombre,

Tipo = mascota.Tipo,

// ... otros campos

FechaCreacion = DateTime.UtcNow

};

_context.Mascotas.Add(mascotaEntity);

await _context.SaveChangesAsync();

}

// 2. CONFIGURACIONES DE ENTITY FRAMEWORK

public class MascotaConfiguration : IEntityTypeConfiguration<MascotaEntity>

{

public void Configure(EntityTypeBuilder<MascotaEntity> builder)

{

builder.HasKey(m => m.Id);

builder.Property(m => m.Nombre).IsRequired().HasMaxLength(100);

builder.Property(m => m.Peso).HasPrecision(5, 2);

// 🗄️ CONFIGURACIÓN DE BASE DE DATOS

builder.HasOne<PropietarioEntity>()

.WithMany()

.HasForeignKey(m => m.PropietarioId);

}

�� Puntos Clave de la Infraestructura:

✅ Implementa las interfaces definidas en el dominio
✅ Maneja Entity Framework, APIs externas, archivos
✅ Convierte entre entidades de dominio y entidades de persistencia
✅ Puede cambiarse sin afectar el dominio

🌐 Capa de API - La Interfaz HTTP

La API expone los endpoints REST para que otros sistemas puedan usar nuestra aplicación:

// �� VETCAREPRO API - Endpoints REST

[ApiController]

[Route("api/[controller]")]

public class MascotasController : ControllerBase

{

private readonly IMediator _mediator;

public MascotasController(IMediator mediator)

{

_mediator = mediator;

}

[HttpPost]

public async Task<ActionResult<Guid>> CreateMascota([FromBody] CreateMascotaRequest request)

{

// �� CONVERTIR Request → Command

var command = new CreateMascotaCommand(

request.Nombre,

request.Tipo,

request.Raza,

request.Sexo,

request.FechaNacimiento,

request.Peso,

request.Color,

request.PropietarioId,

request.Observaciones

);

// ⚡ EJECUTAR usando la capa de aplicación

var result = await _mediator.Send(command);

if (result.IsFailure)

return BadRequest(result.Error);

return CreatedAtAction(nameof(GetMascota), new { id = result.Value }, result.Value);

}

[HttpGet("{id}")]

public async Task<ActionResult<MascotaDto>> GetMascota(Guid id)

{

var query = new GetMascotaByIdQuery(id);

var mascota = await _mediator.Send(query);

if (mascota == null)

return NotFound();

return Ok(mascota);

}

// 📝 DTOs para la API

public record CreateMascotaRequest(

string Nombre,

TipoMascota Tipo,

string Raza,

SexoMascota Sexo,

DateTime FechaNacimiento,

decimal Peso,

string Color,

Guid PropietarioId,

string? Observaciones

);

🔑 Puntos Clave de la API:

✅ Expone endpoints REST
✅ Convierte HTTP requests/responses
✅ No contiene lógica de negocio
✅ Usa MediatR para delegar a la aplicación

🎨 Capa Web - La Interfaz de Usuario

La Web proporciona la interfaz gráfica para que los usuarios interactúen:

// 🎨 VETCAREPRO WEB - Interfaz de usuario con Blazor

@page "/mascotas"

@inject IVetCareProApiService ApiService

<MudText Typo="Typo.h3">🐕 Gestión de Mascotas</MudText>

<MudTextField @bind-Value="_searchTerm"

Label="Buscar mascota..."

AdornmentIcon="@Icons.Material.Filled.Search" />

<MudButton Color="Color.Primary"

StartIcon="@Icons.Material.Filled.Add"

OnClick="OpenCreateDialog">

Registrar Mascota

</MudButton>

@if (_mascotas.Any())

{

<MudTh>Nombre</MudTh>

<MudTh>Acciones</MudTh>

</HeaderContent>

<MudTd>@context.Nombre</MudTd>

<MudTd>@context.Tipo</MudTd>

<MudTd>@context.EdadEnAnios años</MudTd>

<MudTd>

<MudButton Size="Size.Small"

OnClick="@(() => VerDetalle(context.Id))">

Ver

</MudButton>

</MudTd>

</RowTemplate>

</MudTable>

}

</MudCardContent>

</MudCard>

</MudContainer>

@code {

private List<MascotaDto> _mascotas = new();

private string _searchTerm = "";

protected override async Task OnInitializedAsync()

{

await LoadMascotas();

}

private async Task LoadMascotas()

{

// 🌐 LLAMAR a la API

_mascotas = (await ApiService.GetMascotasAsync()).ToList();

StateHasChanged();

}

🔑 Puntos Clave de la Web:

✅ Interfaz de usuario moderna con MudBlazor
✅ Se comunica con la API via HTTP
✅ No contiene lógica de negocio
✅ Experiencia de usuario rica e interactiva

🎯 Flujo Completo: Cómo Funcionan las Capas Juntas

Ejemplo: Registrar una Nueva Mascota

graph TD

A[👤 Usuario llena formulario] --> B[�� Web: Envía datos a API]

B --> C[🌐 API: Recibe HTTP POST]

C --> D[⚡ Application: Crea Command]

D --> E[🏥 Domain: Valida reglas de negocio]

E --> F[💾 Infrastructure: Guarda en BD]

F --> G[🔄 Respuesta vuelve por las capas]

G --> H[👤 Usuario ve confirmación]

1. �� Usuario en la Web:

// Usuario llena formulario y hace clic en "Registrar"

var command = new CreateMascotaCommand("Max", TipoMascota.Perro, "Golden Retriever", ...);

2. 🌐 API recibe la petición:

[HttpPost]

public async Task<ActionResult<Guid>> CreateMascota([FromBody] CreateMascotaRequest request)

{

var command = MapToCommand(request);

var result = await _mediator.Send(command); // ⚡ Delega a Application

return Ok(result.Value);

}

3. ⚡ Application orquesta:

public async Task<Result<Guid>> Handle(CreateMascotaCommand request, CancellationToken cancellationToken)

{

var mascota = Mascota.Create(...); // �� Usa el dominio

await _mascotaRepository.AddAsync(mascota); // 💾 Usa infraestructura

return Result.Success(mascota.Id);

}

4. 🏥 Domain valida reglas:

public static Mascota Create(string nombre, TipoMascota tipo, ...)

{

if (string.IsNullOrEmpty(nombre))

throw new ArgumentException("El nombre es obligatorio");

if (peso <= 0)

throw new ArgumentException("El peso debe ser positivo");

return new Mascota(nombre, tipo, ...);

}

5. 💾 Infrastructure persiste:

public async Task AddAsync(Mascota mascota)

{

var entity = MapToEntity(mascota);

_context.Mascotas.Add(entity);

await _context.SaveChangesAsync();

}

🏆 Beneficios de esta Arquitectura

✅ 1. Dominio Independiente

// �� El dominio NO depende de nada externo

public class Mascota

{

// ✅ Solo lógica de negocio pura

public bool PuedeVacunarse() => EdadEnMeses >= 2;

// ❌ NO hay referencias a Entity Framework

// ❌ NO hay referencias a APIs

// ❌ NO hay referencias a frameworks

}

✅ 2. Fácil Testing

[Test]

public void Mascota_PuedeVacunarse_CuandoEsMayorDe2Meses()

{

// ✅ Test puro del dominio - sin configuraciones

var mascota = Mascota.Create("Max", TipoMascota.Perro, "Golden",

SexoMascota.Macho, DateTime.Today.AddMonths(-3),

15.5m, "Dorado", Guid.NewGuid());

Assert.That(mascota.PuedeVacunarse(), Is.True);

}

✅ 3. Cambios Tecnológicos Fáciles

// 🔄 Cambiar de SQL Server a PostgreSQL

// Solo cambia la Infraestructura, el dominio permanece igual

// 🔄 Cambiar de Blazor a React

// Solo cambia la Web, la lógica de negocio permanece

// 🔄 Cambiar de REST a GraphQL

// Solo cambia la API, el dominio permanece

🎓 Resumen para los Estudiantes

�� Conceptos Clave:

🏥 Dominio = Reglas de Negocio

Es el "cerebro" de la aplicación
Contiene las reglas más importantes
NO depende de nada externo

⚡ Aplicación = Orquestador

Coordina las operaciones
Conecta dominio con infraestructura
Maneja validaciones y mapeos

💾 Infraestructura = Almacén

Persiste datos en base de datos
Conecta con APIs externas
Implementa las interfaces del dominio

🌐 API = Interfaz HTTP

Expone endpoints REST
Convierte HTTP a comandos
No contiene lógica de negocio

�� Web = Interfaz de Usuario

Interfaz gráfica moderna
Se comunica con la API
Experiencia de usuario rica

�� Flujo de Dependencias:

🎨 Web → 🌐 API → ⚡ Application → 🏥 Domain

↗️ 💾 Infrastructure ↗️

¡La magia está en que el dominio está en el centro y todo lo demás depende de él, no al revés! ✨

Juan David García Muñoz

student•

🚀

Juan Sebastian Ramirez Leyva

student•

cuando hablamos de arquitectura limpias a codigo limpio, patrones y principios bien utilizados en una arquitectura es asi?

Carlos Orjuela

student•

Carlos Andrés Moreno Jimenez

student•

En una arquitectura limpia, el dominio (lógica de negocio) es el núcleo del sistema y no depende de elementos externos como bases de datos, interfaces gráficas, frameworks o dispositivos. Sin embargo, estos componentes sí dependen del dominio. Esta independencia permite que la lógica de negocio sea más fácil de probar, ya que no necesita la presencia de dependencias externas para ejecutarse correctamente.

Fredy Alfonso Lancheros Suárez

student•

Cómo se consideran los procesos batch u otros que se ejecutan en procedimientos almacenados en el motor de la DB en cuanto a las arquitecturas limpias? Si bien deberíamos considerar mantener la base de datos como elemento externo, es decir, como repositorio de datos, algunas veces la volumetría de las operaciones no permite que se haga bajo un microservicio, por ejemplo, quedándo así los procesos más pesados del lado de la DB.

Marcel Garcia

student•

Hola, hice una consulta a gemini con el siguiente prompts "cual es la brecha entre la teorio de arquitecturas limpias en sotfware y la implementacion en la practica" y esta fue la respuesta.

La Brecha entre la Teoría de Arquitecturas Limpias y su Implementación Práctica

La teoría de las arquitecturas limpias presenta un ideal de diseño de software, donde los componentes están bien definidos, desacoplados y altamente mantenibles. Sin embargo, la implementación práctica a menudo se encuentra con desafíos y compromisos que pueden generar una brecha entre el modelo teórico y la realidad.

Principales Desafíos en la Implementación:

Complejidad del Dominio:
- Dominios cambiantes: Los requisitos del negocio evolucionan constantemente, lo que puede dificultar mantener una arquitectura limpia a largo plazo.
- Dominios complejos: Dominios altamente especializados pueden requerir modelos de datos y lógica de negocio intrincados, dificultando la aplicación de principios de arquitectura limpia.
Presiones de Tiempo:
- Deadlines ajustados: La presión por entregar rápidamente un producto puede llevar a tomar atajos y comprometer la calidad de la arquitectura.
- Cambios de prioridades: Los cambios constantes en las prioridades pueden dificultar mantener una visión a largo plazo de la arquitectura.
Legado y Tecnologías Existentes:
- Migraciones: Integrar una nueva arquitectura en un sistema existente puede ser un proceso costoso y complejo.
- Dependencias: Las dependencias de tecnologías heredadas pueden limitar las opciones de diseño.
Falta de Experiencia:
- Equipo: No todos los desarrolladores tienen la misma experiencia en diseño de arquitecturas limpias, lo que puede llevar a inconsistencias en la implementación.
- Comunicación: La falta de una comunicación clara entre los miembros del equipo puede dificultar la adopción de una arquitectura común.
Costos:
- Refactorización: Mantener una arquitectura limpia a menudo requiere refactoring continuo, lo cual puede ser costoso en términos de tiempo y recursos.
- Herramientas: La implementación de una arquitectura limpia puede requerir el uso de herramientas y tecnologías específicas, lo que puede aumentar los costos.

Cómo Minimizar la Brecha:

Compromisos Conscientes: Es importante reconocer que los compromisos son inevitables. Sin embargo, estos deben ser tomados de forma consciente y documentada.
Evolución Gradual: En lugar de intentar una refactorización completa, se pueden realizar cambios incrementales para mejorar la arquitectura con el tiempo.
Pruebas Continuas: Las pruebas unitarias, de integración y end-to-end son esenciales para garantizar la calidad y la mantenibilidad del software.
Documentación: Una documentación clara y actualizada de la arquitectura es fundamental para facilitar la colaboración y la transición de los miembros del equipo.
Capacitación: Invertir en la capacitación de los desarrolladores en principios de arquitectura limpia puede ayudar a mejorar la calidad del software.
Herramientas de Apoyo: El uso de herramientas de diseño, modelado y análisis puede ayudar a visualizar y validar la arquitectura.

En resumen, la implementación de una arquitectura limpia en la práctica requiere un equilibrio entre los ideales teóricos y las restricciones del mundo real. Al comprender los desafíos y adoptando las estrategias adecuadas, es posible construir sistemas de software más robustos, mantenibles y escalables.