Si quieres dejar de ser junior, ponte la gorra de albañil 👷♂️
Hola amante del código limpio y los if bien colocaditos,
Hoy te voy a contar una de esas cosas que vas a necesitar si quieres dar el salto a programador senior.
Y es muy fácil.
Tienes que ponerte el gorro de obra.
Porque vamos a montar tu casa.
-¿Cómo?
Sí, sí, porque hoy te voy a hablar de la arquitectura de software.
¡Así en general!
-Pero… y esto, ¿qué tiene que ver con mi casa?
Tranquilo… ahora vamos, de momento coge asiento, dale un sorbo a tu café, que te lo voy a explicar como si fueras el nuevo del equipo que acaba de salir de la carrera y entra en su primer proyecto.
Y como siempre. Empezamos por el principio.
¿Qué es eso de la arquitectura de software?
Vale piensa ahora en tu casa y que la estás construyendo tú desde el principio.
¿Te vas a poner como un loco a poner ladrillos y a construirla sin planos?
Esto a lo mejor en Minecraft te funciona…. Pero en la vida real no creo.
Además…. Seguro que si luego quieres añadir una segunda planta…. upsi…. o arreglar las tuberías que van por toda la casa…. upsi…
Y ahora es cuando empiezan los problemas. ☠️
Pues en el mundo de la programación pasa IGUAL.
IGUAL.
Por eso se han establecido una serie de arquitecturas, que te ayudan a organizar la construcción de la casa. Y que las podemos describir como el plano de construcción.
¿Dónde va qué?
¿Quién habla con quién?
Y lo más importante: ¿cómo hacer que todo sea escalable, mantenible y entendible con el paso del tiempo?
Porque escribir código… lo puede hacer cualquiera (de hecho creo firmemente que esto el día de mañana lo hará la IA).
Pero escribir buen software que dure… eso ya es otro nivel.
¿Y por qué debería importarme si yo solo quiero que funcione?
Buena pregunta, padawan.
Aquí van unas razones por las que la arquitectura te tiene que importar, y mucho:
✅ Mantenibilidad → Cuando hay bugs (y los habrá), querrás entender qué está pasando sin llorar, además que la documentación suele brillar por su esencia.
✅ Escalabilidad → Que no se te caiga la app cuando pasas de 10 a 10.000 usuarios.
✅ Testabilidad → Poder hacer tests sin tener que montar toda la aplicación.
✅ Separación de responsabilidades → Cada cosa en su sitio, como decía tu madre.
✅ Facilita el trabajo en equipo → Si todo está organizado, cada uno sabe qué tocar y qué no romper.
¿Pero no vale con tener carpetas “controller”, “service” y “repository”?
A ver…
Eso es como decir que porque tu casa tiene salón, cocina y baño ya tiene buena arquitectura.
Puede estar todo en una sola planta… o puede que para ir al baño tengas que pasar por la cocina y subir al desván.
La clave no es solo tener capas, sino saber cómo se relacionan entre sí y cuál es su responsabilidad.
-Vale, me has convencido. ¿Y por dónde empiezo?
¿Y qué tipos de arquitecturas hay?
Bueno, antes de nada decirte que la idea del email de hoy era que te quede claro las bases, nunca mejor dicho, y por qué te vas haciendo una idea de por qué tienes que definirlo.
No te preocupes, no vamos a entrar hoy en detalles técnicos. Lo dicho, sin detalles técnicos, pero para que te vayan sonando:
🏠 Arquitectura en capas → La de toda la vida: Controller, Service, Repository.
🧅 Onion Architecture → Capas concéntricas, donde el dominio está en el centro.
🔌 Hexagonal Architecture (Ports & Adapters) → Ideal para separar el núcleo del sistema de lo externo (bases de datos, APIs, etc).
🧱 Clean Architecture → Un paso más allá, muy centrada en el dominio y en aislar dependencias.
En los próximos posts te iré contando cómo funcionan cada una, cuándo se usan, y qué ventajas tienen.
Resumen de lo que te cuento:
🔹 La arquitectura no es un capricho de los arquitectos del software.
🔹 Es lo que permite que una app crezca sin convertirse en una montaña de fango.
🔹 Y aunque tú estés empezando, cuanto antes entiendas la base… mejor programador vas a ser.
P.D: Me ha llegado alguna oferta de trabajo para ser arquitecto de casas…..así que repasa bien los conceptos, porque no todo el mundo los tiene.
Nos leemos en una semana.