El Arte de Separar: Arquitectura en Capas en Web, Mobile y Desktop

Bienvenidos a CodeWithBotina. Si alguna vez has sentido que tu código es un laberinto donde una pequeña modificación en la base de datos rompe la interfaz de usuario, es porque te falta "capas".

La Arquitectura en Capas (Layered Architecture) es el patrón más utilizado en el mundo. Su principio es la Separación de Preocupaciones (Separation of Concerns): cada parte del código tiene una única responsabilidad y solo se comunica con la capa inmediatamente inferior.

1. Las 3 Capas Fundamentales

Aunque pueden ser más, la mayoría de los sistemas se dividen en estas tres:

Capa de Presentación (UI): Lo que el usuario ve y toca. Captura eventos y muestra datos.
Capa de Lógica de Negocio (Domain): El cerebro. Aquí residen las reglas, cálculos y validaciones.
Capa de Datos (Data/Infrastructure): Donde viven las bases de datos, APIs externas o el sistema de archivos.

2. Adaptación por Plataforma

🌐 Web (APIs)

En una API REST (Node.js, Spring Boot, .NET), las capas suelen verse así:

Controllers: Reciben la petición HTTP y validan los parámetros.
Services: Ejecutan la lógica (ej. "Si el usuario es VIP, aplicar 10% de descuento").
Repositories: Realizan las consultas SQL o interactúan con el ORM.

📱 Aplicaciones Móviles (Android/iOS)

Aquí la arquitectura evoluciona a patrones como MVVM (Model-View-ViewModel) o Clean Architecture:

UI (Activity/SwiftUI): Solo muestra estados.
ViewModel/Use Cases: Actúan como la lógica que sobrevive a los cambios de rotación de pantalla.
Remote/Local Data: Gestionan si los datos vienen de una API o del almacenamiento interno (SQLite).

🖥️ Aplicaciones de Escritorio (Desktop)

En entornos como WPF o JavaFX, la separación es vital para mantener el rendimiento:

View: XAML o archivos FXML.
Business Logic: Clases que procesan archivos locales o hardware (sensores).
DataAccess: Drivers para bases de datos locales o conectores de red.

3. ¿Por qué usarla en 2026?

Mantenibilidad: Puedes cambiar tu base de datos de MySQL a PostgreSQL sin tocar una sola línea de la interfaz.
Testeabilidad: Puedes probar la lógica de negocio sin necesidad de abrir un navegador o un emulador.

Fuentes verificables para seguir aprendiendo:

Martin Fowler (Patterns of Enterprise Application Architecture): La biblia de la organización de software. martinfowler.com
Microsoft Learn: Guía sobre estilos de arquitectura (N-tier applications). learn.microsoft.com
Google Developers: Guía de arquitectura de apps móviles (Android). developer.android.com

Construye software sólido, no castillos de naipes. Nos vemos en el próximo post de CodeWithBotina.