Cuando pensamos en arquitectura de software, normalmente imaginamos diagramas llenos de cajas y flechas.
Algo como esto:
Cliente
↓
API
↓
Servicio
↓
Base de Datos
Eso está bien, pero en realidad una buena arquitectura por sí sola no garantiza que un proyecto se mantenga sano con el paso del tiempo.
Existe otro ingrediente igual de importante: definir las reglas de compromiso (Rules of Engagement).
Es decir:
Eso es precisamente lo que intenta explicar la imagen.
Primer nivel: la arquitectura
La arquitectura responde una pregunta muy simple:
¿Cómo debería funcionar el sistema?
Por ejemplo, imagina un restaurante.
La arquitectura podría ser algo tan sencillo como:
Cliente
↓
Mesero
↓
Cocina
↓
Mesero
↓
Cliente
Todo el mundo entiende el flujo.
En una aplicación Java ocurre exactamente igual.
Usuario
↓
REST API
↓
Servicio
↓
Repositorio
↓
Base de datos
No estamos hablando todavía de código.
Estamos definiendo el modelo mental que todos los desarrolladores deben compartir.
Si todos entienden ese flujo, será mucho más difícil que alguien termine escribiendo consultas SQL directamente desde el controlador REST.
Segundo nivel: las reglas que siempre debemos seguir
Aquí aparecen los llamados Critical Patterns.
Son prácticas que el equipo decidió convertir en reglas.
No porque Java las obligue.
No porque Spring o Quarkus las exijan.
Sino porque la experiencia demuestra que producen mejores resultados.
Por ejemplo:
✅ Siempre validar la entrada de datos.
✅ Siempre escribir pruebas unitarias.
✅ Siempre usar inyección de dependencias.
✅ Siempre registrar errores con logs estructurados.
Es parecido a conducir un automóvil.
Nadie te obliga físicamente a usar el cinturón de seguridad.
Pero todos sabemos que hacerlo reduce enormemente el riesgo.
Las buenas prácticas funcionan igual.
Tercer nivel: las cosas prohibidas
Esta es probablemente la parte más interesante.
Muchas empresas documentan únicamente las buenas prácticas.
Pero los equipos más maduros también documentan aquello que está prohibido.
Los llamados Anti-Patterns.
Son errores que normalmente alguien ya cometió.
Y que costaron tiempo, dinero o incluso clientes.
Por ejemplo:
❌ Nunca hacer commit directamente a la rama main.
¿Por qué?
Porque alguien ya rompió producción haciendo exactamente eso.
Otro ejemplo.
❌ Nunca confiar en un archivo recibido sin validarlo.
¿Por qué?
Porque un archivo corrupto podría hacer fallar todo el sistema.
O uno muy común en Java:
❌ Nunca acceder a la base de datos desde un controlador REST.
No significa que sea imposible.
Significa que rompe la arquitectura y vuelve el código difícil de mantener.
Un ejemplo cotidiano
Imagina que construyes una casa.
La arquitectura define cosas como:
Pero eso no basta.
También necesitas reglas como:
Siempre
Y reglas como:
Nunca
conectar demasiados aparatos en un mismo enchufe.
perforar una pared sin revisar dónde pasan los cables.
dejar velas encendidas cuando sales.
La arquitectura organiza la casa.
Las reglas evitan accidentes.
Lo mismo ocurre en el desarrollo de software
Un proyecto puede tener una arquitectura excelente.
Sin embargo, si cada desarrollador programa como quiere, tarde o temprano aparecerán problemas.
Por eso los equipos de ingeniería más experimentados trabajan con tres niveles muy claros:
Arquitectura
Así está diseñado el sistema.
Patrones obligatorios
Así hacemos las cosas en este equipo.
Anti-patrones
Estos errores ya los vivimos y no queremos volver a cometerlos.
La verdadera enseñanza
La frase de la diapositiva resume una idea muy poderosa:
Los modelos mentales de alto nivel evitan desviaciones en la arquitectura, mientras que los anti-patrones explícitos evitan que los errores del pasado vuelvan a repetirse.
En otras palabras:
La arquitectura te dice cómo construir el sistema.
Los patrones te dicen cómo escribir un buen software.
Los anti-patrones te recuerdan qué errores nunca debes repetir.
Cuando un equipo documenta estos tres aspectos, deja de depender únicamente de la experiencia de sus desarrolladores. El conocimiento se vuelve parte del proyecto, facilitando que nuevos integrantes se integren rápidamente, que el código sea más consistente y que los errores del pasado no se conviertan en problemas recurrentes. Esa es una de las diferencias entre un proyecto que simplemente funciona y uno que puede mantenerse y evolucionar durante años.
Enjoy!
Joe
