Artefactos – Desarrollo de Software

📚 Arquitectura en Capas

Los artefactos están organizados siguiendo el patrón de arquitectura en capas (Layered Architecture), que separa las responsabilidades en tres niveles fundamentales para aplicaciones empresariales.

● Separación de Responsabilidades

Cada capa tiene un propósito bien definido y se comunica solo con las capas adyacentes.

● Independencia Tecnológica

Las capas pueden evolucionar independientemente usando diferentes tecnologías y frameworks.

● Facilidad de Pruebas

Cada capa puede ser probada de forma aislada mediante mocks y stubs de las dependencias.

🏗️ Responsabilidades de cada Capa

Haz clic en cada capa para ver sus responsabilidades específicas:

Responsabilidad: Punto de entrada del sistema. Expone endpoints HTTP y maneja la comunicación con clientes externos.

Recibir peticiones HTTP (GET, POST, PUT, DELETE)
Validar formato de datos de entrada
Serializar/deserializar JSON
Manejar códigos de respuesta HTTP
Gestionar autenticación y autorización
NO contiene lógica de negocio

↓

Responsabilidad: Núcleo del sistema. Implementa reglas de negocio y coordina operaciones.

Implementar reglas de negocio y validaciones
Coordinar operaciones entre diferentes entidades
Gestionar transacciones
Aplicar cálculos y transformaciones
Orquestar flujos de trabajo complejos
NO conoce detalles de HTTP o base de datos

↓

Responsabilidad: Gestiona el acceso y almacenamiento de datos.

Ejecutar consultas SQL o queries ORM
Mapear objetos a tablas (ORM)
Gestionar conexiones a base de datos
Implementar operaciones CRUD
Optimizar acceso a datos (índices, caching)
NO contiene lógica de negocio

🎯 Conceptos Fundamentales

🎯 Separación de Responsabilidades

Cada capa tiene una responsabilidad única y bien definida. La API maneja comunicación HTTP, Business Logic implementa reglas de negocio, y Persistencia gestiona datos.

Beneficio: Los cambios en una responsabilidad no afectan a las demás. Por ejemplo, cambiar de MySQL a PostgreSQL solo requiere modificar la capa de Persistencia.

🔗 Cohesión

Mide qué tan relacionadas están las responsabilidades dentro de una capa. En esta arquitectura, cada capa tiene alta cohesión porque todos sus elementos están enfocados en una única tarea.

Ejemplo: La capa de Business Logic solo contiene lógica de negocio. No mezcla validaciones de HTTP ni queries SQL, manteniendo alta cohesión.

🔌 Acoplamiento

Mide el grado de dependencia entre capas. Esta arquitectura busca bajo acoplamiento mediante interfaces y abstracciones.

Ejemplo: La Business Logic no conoce si usa MySQL o MongoDB. Solo conoce una interfaz (Repository) que la Persistencia implementa.

🔄 Ejemplo: Flujo de una Petición

Caso de uso: Un cliente quiere crear un nuevo pedido

1

API REST

Recibe POST /orders con JSON del pedido. Valida formato y autenticación.

2

Business Logic

Verifica reglas de negocio (stock disponible, límite de crédito del cliente, precios válidos).

3

Persistencia

Guarda el pedido en la base de datos y actualiza el inventario.

4

Persistencia

Retorna el ID del pedido creado a Business Logic.

5

Business Logic

Puede ejecutar lógica adicional (enviar email, generar factura) y retorna el resultado.

6

API REST

Retorna HTTP 201 Created con el pedido creado en JSON.

🎯 Separación Clara

Cada capa tiene responsabilidades bien definidas, lo que facilita entender qué hace cada parte del sistema. Un desarrollador nuevo puede enfocarse en una capa a la vez.

🔧 Mantenibilidad

Los cambios están contenidos en una capa. Cambiar la base de datos de MySQL a PostgreSQL solo afecta la capa de Persistencia, sin tocar Business Logic ni API.

🧪 Facilidad de Testing

Cada capa puede probarse independientemente. Puedes testear Business Logic sin necesitar una base de datos real, usando mocks de la capa de Persistencia.

♻️ Reutilización

La misma Business Logic puede usarse desde diferentes APIs (REST, GraphQL, gRPC) o desde una interfaz web, móvil o consola sin duplicar código.

👥 Trabajo en Equipo

Equipos diferentes pueden trabajar en paralelo en distintas capas sin pisarse. Un equipo en API, otro en Business Logic y otro en Persistencia.

🔒 Seguridad

La Business Logic está protegida. No es posible acceder directamente a la base de datos sin pasar por las validaciones de negocio, previniendo operaciones inválidas.

📦 Complejidad Adicional

Para operaciones simples (CRUD básico), atravesar tres capas puede parecer excesivo. Requiere crear múltiples clases e interfaces incluso para funcionalidad trivial.

⏱️ Overhead de Performance

Cada capa agrega llamadas a métodos y posible serialización de datos. Para sistemas de alta performance, este overhead puede ser significativo.

🔀 Rigidez

Los cambios que afectan múltiples capas requieren modificaciones en cascada. Un cambio en el modelo de datos puede requerir actualizar Persistencia, Business Logic y API.

📝 Código Repetitivo

Los DTOs (Data Transfer Objects) deben definirse en cada capa. Esto genera clases similares que mapean datos entre capas, aumentando el código a mantener.

🎓 Curva de Aprendizaje

Desarrolladores junior pueden tardar en comprender dónde va cada cosa. Requiere disciplina para no romper la arquitectura (ej: poner SQL en Business Logic).

🔍 Debugging Complejo

Rastrear un bug puede requerir seguir el flujo a través de múltiples capas. El stack trace es más profundo y puede ser difícil identificar dónde ocurrió el problema.

💡 Conclusión: La arquitectura por capas es excelente para sistemas complejos donde la mantenibilidad y testing son prioritarios. Sin embargo, para aplicaciones simples o prototipos, puede ser sobre-ingeniería. La clave es evaluar las necesidades del proyecto antes de decidir la arquitectura.