Arquitectura en capas: controller, servicio y repositorio

Curso Profesional de Arquitectura de Software

Contenido del curso

Introducción al curso

1
Curso Profesional de Arquitectura de Software
02:36 min

Atributos de calidad

Patrones de arquitectura

Diseño de una arquitectura

Modelado y documentación de arquitectura

Tomar examen

Cursos Empresas Blog Live Conf Eventos Precios

0:003:14

Arquitectura en capas: controller, servicio y repositorio

Curso Profesional de Arquitectura de Software

Clase 15 de 43

Clase 15 / 43

Recursos

La arquitectura en capas (o layered) separa responsabilidades para lograr claridad, aislación y mantenibilidad. Con frecuencia se organiza en tres o cuatro capas, priorizando una comunicación estricta de arriba hacia abajo. Este enfoque encaja en un monolito y también en partes de sistemas distribuidos gracias a su orden y estabilidad.

¿Qué es la arquitectura en capas y cómo se organiza?

La idea central es que cada capa sea responsable de un concepto global de la aplicación. En el ejemplo, se distinguen aplicación, dominio y datos; a veces aparece una cuarta capa de presentación.

Capa de aplicación: orquesta casos de uso y coordina flujos. Un controller vive aquí y conversa con dominio.
Capa de dominio: incluye entidades y servicios del negocio. Se aísla de detalles de uso por parte del usuario.
Capa de datos: implementa acceso a base de datos o colecciones en memoria por medio de un repository.
Cantidad de capas: depende de la aplicación, aunque es habitual ver tres o cuatro.

¿Qué rol cumplen controller, servicio y repositorio?

Controller: endpoint o interfaz que recibe la petición del usuario y delega en dominio.
Servicio de dominio: encapsula reglas del negocio y usa entidades para representar el estado en memoria.
Repository: sabe cómo acceder y buscar en la fuente de datos, sin conocer al usuario ni al dominio.

¿Qué implica la aislación entre capas?

Permite trabajar en capas inferiores sin preocuparse por las superiores.
Evita que detalles de interacción con el usuario contaminen el modelo de dominio.
Refuerza límites claros entre aplicación, dominio y datos.

¿Cómo se comunican las capas: de arriba hacia abajo?

La regla del patrón indica que la comunicación va siempre de arriba hacia abajo. Una capa inferior, con detalles de bajo nivel, no debería invocar a una superior que abstrae interacción con usuario o modelado del dominio.

¿Dónde encaja la lógica de presentación?

Una capa superior puede dedicarse a lógica de presentación, como la vista o algún tipo de server side rendering. Así se mantiene separada de dominio y datos.

¿Qué ejemplo práctico muestra el carrito de compras?

Un usuario solicita su carrito de compras. Puede hacerlo mediante un pedido HTTPS o desde una aplicación de escritorio. El flujo respeta el orden de capas y retorna la respuesta hacia arriba.

El controller recibe la solicitud y consulta al servicio de carrito.
El servicio usa la entidad carrito para representarlo en memoria.
La búsqueda se realiza a través del repository, que sabe cómo acceder a los datos.
El repository responde al servicio con el carrito correspondiente.
La respuesta sube: servicio al controller, y controller al usuario.

¿Se usa en monolitos y en sistemas distribuidos?

La arquitectura en capas se implementa en un monolito: todo se despliega junto. También puede aplicarse dentro de sistemas distribuidos, donde cada parte se diseña en capas por su mantenibilidad.

¿Tienes dudas o un caso real donde aplicar capas? Cuéntalo en comentarios y enriquezcamos la solución juntos.

Miguel Angel Reyes Moreno

Hace 2 años

Ejemplo del directorio de archivos del e-commerce con la arquitectura de capas:

/ecommerce-app

│

├── /src

│ ├── /presentation

│ │ ├── /controllers

│ │ │ ├── AuthController.js # Controlador para autenticación de usuarios

│ │ │ ├── ProductController.js # Controlador para productos

│ │ │ ├── CartController.js # Controlador para el carrito

│ │ │ └── OrderController.js # Controlador para pedidos

│ │ ├── /views

│ │ │ ├── /auth

│ │ │ │ ├── login.ejs # Vista para login

│ │ │ │ └── register.ejs # Vista para registro

│ │ │ ├── /products

│ │ │ │ ├── index.ejs # Vista para listar productos

│ │ │ │ └── show.ejs # Vista para mostrar detalles del producto

│ │ │ └── /cart

│ │ │ ├── index.ejs # Vista para mostrar carrito

│ │ │ └── checkout.ejs # Vista para pago

│ │ └── /routes

│ │ ├── authRoutes.js # Rutas para autenticación

│ │ ├── productRoutes.js # Rutas para productos

│ │ ├── cartRoutes.js # Rutas para el carrito

│ │ └── orderRoutes.js # Rutas para pedidos

│

├── /application

│ ├── /services

│ │ ├── AuthService.js # Lógica de negocio para autenticación

│ │ ├── ProductService.js # Lógica de negocio para productos

│ │ ├── CartService.js # Lógica de negocio para el carrito

│ │ └── OrderService.js # Lógica de negocio para pedidos

│ └── /dtos

│ ├── UserDTO.js # Objeto de Transferencia de Datos para el usuario

│ ├── ProductDTO.js # DTO para producto

│ └── OrderDTO.js # DTO para pedido

│

├── /domain

│ ├── /models

│ │ ├── User.js # Modelo de dominio para usuarios

│ │ ├── Product.js # Modelo de dominio para productos

│ │ ├── Cart.js # Modelo de dominio para carrito

│ │ └── Order.js # Modelo de dominio para pedidos

│ ├── /repositories

│ │ ├── UserRepository.js # Repositorio para usuarios

│ │ ├── ProductRepository.js # Repositorio para productos

│ │ ├── CartRepository.js # Repositorio para el carrito

│ │ └── OrderRepository.js # Repositorio para pedidos

│ └── /entities

│ ├── UserEntity.js # Entidad de usuario

│ ├── ProductEntity.js # Entidad de producto

│ ├── CartEntity.js # Entidad de carrito

│ └── OrderEntity.js # Entidad de pedido

│

├── /infrastructure

│ ├── /database

│ │ ├── db.js # Configuración de la base de datos

│ │ ├── UserSchema.js # Esquema de base de datos para usuario

│ │ ├── ProductSchema.js # Esquema de base de datos para productos

│ │ ├── CartSchema.js # Esquema de base de datos para carrito

│ │ └── OrderSchema.js # Esquema de base de datos para pedidos

│ ├── /services

│ │ ├── PaymentGateway.js # Implementación de un servicio de pasarela de pagos

│ │ └── EmailService.js # Servicio para enviar correos electrónicos

│ └── /migrations

│ └── initialMigration.js # Archivo de migración inicial para la base de datos

│

├── /config

│ ├── config.js # Configuraciones generales del proyecto (puerto, claves, etc.)

│ └── db.config.js # Configuración específica de la base de datos

│

├── /middlewares

│ ├── authMiddleware.js # Middleware para proteger rutas privadas

│ └── errorHandler.js # Middleware para manejar errores

│

├── /public

│ ├── /css

│ │ └── styles.css # Archivos CSS

│ ├── /images

│ │ └── logo.png # Imágenes del sitio

│ └── /js

│ └── scripts.js # Archivos JavaScript del frontend

│

├── app.js # Punto de entrada de la aplicación

├── package.json # Dependencias del proyecto

└── README.md # Documentación del proyecto

Explicación:

Presentación (Presentation):
- Aquí se encuentran los controladores, vistas y rutas, lo que corresponde a la interacción directa con el usuario. La capa de presentación es responsable de recibir las peticiones y devolver las respuestas.
- Las vistas (en este caso usando EJS) se encargan de generar la interfaz de usuario que se presenta en el navegador.
Aplicación (Application):
- Esta capa contiene los servicios que manejan la lógica de negocio. Son los encargados de coordinar las operaciones entre la capa de presentación y la capa de dominio. Aquí se maneja toda la lógica de procesamiento de datos y validación.
- Los DTOs (Data Transfer Objects) son utilizados para transferir datos entre las capas y para garantizar que solo la información relevante sea pasada entre ellas.
Dominio (Domain):
- Es la parte central de la aplicación y contiene las entidades y modelos de dominio, que representan los conceptos fundamentales del negocio (usuarios, productos, pedidos).
- Los repositorios son responsables de interactuar con las bases de datos u otras fuentes de datos externas y devolver las entidades de dominio. Esta capa es independiente de la infraestructura de datos específica.
Infraestructura (Infrastructure):
- Aquí se encuentran las implementaciones específicas de servicios externos (como bases de datos o pasarelas de pago) que se utilizan para la persistencia de datos y comunicación con otros sistemas.
- También incluye la configuración de la base de datos y los esquemas utilizados en las migraciones de la base de datos.
Config:
- Archivos de configuración global del proyecto, incluyendo configuraciones de la base de datos, claves secretas, puertos, etc.
Middlewares:
- Esta capa incluye middlewares personalizados, como la autenticación para proteger rutas y el manejo de errores para capturar excepciones a nivel global.
Public:
- Contiene archivos estáticos que son accesibles directamente desde el navegador (CSS, JavaScript, imágenes).
app.js:
- El archivo principal que inicia la aplicación, configurando las rutas, middlewares, y el servidor web.

Comentarios (30)30 comentarios

Carlos Eduardo Diaz Polanco

Hace 8 años

Viberth Gonzalez

Hace 7 años

Elmer Padilla Espinoza

Hace 6 años

Mauricio Costanzo

J. Sebastián Botello. H.

Hace 3 años

Christian Gómez

Harold Celis

Hace 4 años

Edinson Padrón

Mijael Rodrigo Callejas Flores

Abril Darynka Tapia Sosa

Miguel Peláez

Albin Anthony Hinostroza Macavilca

Hace 5 años

Mauricio Pavan

Jecsham Castillo

JUAN PABLO MAYORGA MENDIETA

José Iván Sandoya

Miller Alexander Botina Caceres

Gustavo Restrepo

Cristian Blandon

Rafael Varela Pérez

William Schnaider Torres Bermon

Jorge Arturo Pintor Morales

Kevin Toruño

Introducción al curso

Curso Profesional de Arquitectura de Software

Atributos de calidad

Qué son los atributos de calidad en software

Cómo medir idoneidad funcional en software

Qué es eficiencia de ejecución en software

Cómo medir interoperabilidad y coexistencia

Qué es la usabilidad y sus 6 dimensiones

Cómo medir confiabilidad en software

Los 5 pilares de seguridad en software

Cómo garantizar mantenibilidad con tests

Adaptabilidad vs capacidad de instalación vs reemplazo

Tensiones entre atributos de calidad de software

Atributos de calidad según fase de empresa

Patrones de arquitectura

Qué es un patrón de arquitectura

Modelo vista controlador: cómo separar responsabilidades

Arquitectura en capas: controller, servicio y repositorio

Event sourcing vs bases relacionales

Qué es la arquitectura microkernel

Arquitectura Comparte Nada con Map Reduce

Patrón de microservicios: cuándo y cómo

Qué es CQRS y cómo separa lectura de escritura

Arquitectura hexagonal: puertos y adaptadores

Qué son los contextos delimitados en DDD

Cómo combinar patrones de arquitectura

Evolución de patrones desde monolito a microservicios

Diseño de una arquitectura

Cómo traducir requerimientos en decisiones arquitectónicas

Conectores en arquitectura: tipos y cuándo usarlos

Llamadas asíncronas vs síncronas vs cliente-servidor

Conector enrutador vs difusión: Twitter

Conectores cola, repositorio y pub/sub

Framework de diseño orientado a atributos

Cómo detectar fallas y reparar sistemas

Cómo recuperar y prevenir fallas en sistemas

Tácticas para confinar modificaciones

Cómo prevenir efectos dominó en software

Tácticas para controlar eficiencia de ejecución

Cómo detectar, resistir y recuperarse de ataques

Cómo probar que el software funciona correctamente

Cómo controlar la usabilidad con tácticas

Cómo validar arquitectura con ATAM y métricas

Evolución de arquitectura: startup a gran escala

Modelado y documentación de arquitectura

Cómo documentar arquitectura que no se erosione

Cómo sincronizar arquitectura y código fuente

Cómo aplicar atributos de calidad en proyectos

Arquitectura en capas: controller, servicio y repositorio