Hoy va de cebollas la cosa… y de muchas capas 🧅
Hola amante de los proyectos bien organizados y de las cebollas,
Hace poco te conté qué era esto de la arquitectura en mundo de la programación y por qué era importante que montases unos buenos cimientos antes de ponerte como loco a picar código.
Pues hoy toca ver una de esas arquitecturas famosas que podemos usar y que a más de alguno le hará llorar… (lo sé… chiste malo)
La arquitectura cebolla…. U Onion Architecture (para cuando te pregunten en inglés).
¿Qué es eso de Onion Architecture?
Vale…. Sencillo, tienes que imaginarte una cebolla, normal, me da igual el color y el tamaño.
Una cebolla 🧅.
¿Lo tienes?
Vale, y, ¿qué tiene una cebolla?
Capas.
Muchas capas.
Una encima de otra, protegiendo lo que hay dentro.
Pues eso mismo es Onion Architecture.
Fin del correo….
No hombre.
Vamos a seguir explicándolo un poco más….
¿Y cuál es la ventaja de esta arquitectura?
Que te deja organizar el proyecto en base a un “núcleo” central, en donde está lo más importante de la aplicación; el dominio (es decir, las reglas de negocio).
Y las demás capas solo existen para protegerlo.
-“¡Aaaahhh!!! Ya va cogiendo sentido”
¿Y cómo se organizan esas capas?
Pues muy fácil….
Te lo cuento de dentro hacia afuera:
Dominio (el núcleo):
Aquí vas a poner tus entidades, tus reglas de negocio, todo lo que hace única tu aplicación.
💬 Ejemplo: La lógica de que un pedido no puede tener cantidad negativa.
Aplicación (capa intermedia):
Aquí tienes que poner los distintos casos de uso o servicios que orquestan acciones.
💬 Ejemplo: "Crear un pedido", "Enviar un email de confirmación".
Infraestructura (la capa más externa):
Aquí conectas con el mundo exterior: bases de datos, APIs, servicios externos.
💬 Ejemplo: Guardar un pedido en MySQL, enviar un correo con SMTP o el servicio REST que recibe un nuevo pedido.
¿La clave?
👉 Las capas externas dependen de las internas.
👉 Pero las internas no saben nada de las externas.
Así protegemos lo más importante (el dominio) de los cambios del exterior.
¿Y todo esto para qué?
Mira, imagina que el día de mañana le da un venazo a tu cliente o a ti mismo, y quieres cambiar la base de datos, vas a pasar de MySQL a MongoDB.
O por ejemplo tienes que llamar a otra API de correos u otro endpoint (esto sí es más común)
(Modo voz de vendedor de teletienda - ON)
¡¡Pues si utilizas Onion Architecture olvídate de todos tus problemas!!
¡Olvídate de tener que tocar el núcleo de tu aplicación!
-”Y ahora por el precio de 999,99€ te llevas 2 Onion architectures”
(Modo voz de vendedor de teletienda - OFF)
¿Un ejemplo sencillo para que lo visualices mejor?
Pero Goico…. Y mi ejemplo.
Mira, piensa en una cafetería.
El dominio: preparar café, servirlo caliente, cobrar.
La aplicación: tomar pedidos, enviar el pedido a cocina, gestionar pagos.
La infraestructura: la persona que atiende, el datáfono de la tarjeta, el móvil donde te mandan las reservas.
Si mañana cambias la cafetera por una nueva superautomática…
¡El proceso de servir café sigue siendo el mismo!
No tienes que volver a enseñar a los camareros a preparar café desde cero.
Bueno…. Vale… me vas convenciendo…
¿Qué ventajas tiene para que lo pueda explicar en mi proyecto?
✅ El núcleo es muy fácil de mantener y testear.
✅ Tu aplicación es mucho más resistente a cambios.
✅ Organizar el proyecto se vuelve más natural.
✅ Favorece la separación de responsabilidades.
P.D: ¿Te gustaría que te prepare un ejemplo sencillo en Java o en pseudocódigo para entender mejor cómo se implementa?
¡Respóndeme y si sois varios, monto una mini-guía!
Nos leemos en una semana.
"No tienes que volver a enseñar a los camareros a preparar café desde cero." Creo que nos quedariamos con procesos antiguos. No me termina de cerrar. Seguire leyendo otras entregas a ver si el complicado soy yo.