Primeros pasos con Laravel

Comencé con Laravel, un framework que sigue el patrón MVC clásico. Fue mi puerta de entrada al mundo del desarrollo web y me permitió comprender cómo estructurar aplicaciones, separar responsabilidades y manejar la lógica de negocio junto con las vistas. Aunque era un enfoque monolítico, me dio una base sólida para entender cómo funcionan los sistemas en producción.

Transición a Java y Python

Con el tiempo me especialicé en Java (Spring Boot) y Python (Django), que se convirtieron en mis principales lenguajes de trabajo.

• En proyectos personales con Java reforcé mi dominio del ciclo completo de aplicaciones, desde el diseño hasta el despliegue.

• Con Django, desarrollé un proyecto sencillo que mostraba imágenes de APIs de perros y gatos. Lo interesante fue aplicar principios SOLID en un sistema pequeño: el reto no estuvo en la complejidad técnica, sino en llevar la teoría a la práctica. El resultado fue un código muy bien organizado y fácil de seguir, lo que me confirmó que incluso proyectos simples pueden ser un buen campo de entrenamiento para aplicar buenas prácticas.

Arquitectura hexagonal y vertical slicing (proyecto personal)

En un proyecto personal experimenté con arquitectura hexagonal y vertical slicing. Aunque era un sistema pequeño, me permitió comprobar cómo la separación de responsabilidades y la organización interna aportan claridad. La experiencia fue más un ejercicio de disciplina que de resolución de problemas técnicos, pero me ayudó a interiorizar conceptos que luego serían útiles en proyectos más grandes.

Backend for Frontend (BFF) en entorno profesional

En el trabajo tuve la oportunidad de diseñar un Backend for Frontend (BFF), con servicios separados para web y móvil. Este patrón me enseñó cómo la arquitectura puede adaptarse a las necesidades de cada cliente, ofreciendo una capa intermedia que simplifica la comunicación entre frontends y backends. El BFF se sitúa en un punto intermedio entre monolitos y microservicios: no es tan complejo como un sistema distribuido completo, pero tampoco tan rígido como un monolito. Su valor está en la flexibilidad y en la orientación a la experiencia del usuario.

Lo que viene: monolito modular y microservicios

Mi siguiente paso es trabajar con un monolito modular, un enfoque que organiza el sistema en módulos internos y que sirve como preparación natural para escalar hacia microservicios. En este camino me resuena mucho la frase de Martin Fowler:

"You shouldn't start with a microservices architecture. Instead begin with a monolith, keep it modular and split it into microservices once the monolith becomes a problem."

Más que seguir tendencias, lo importante es entender cuándo aplicar cada patrón y cómo se conecta con las necesidades reales de un proyecto.

Conclusión

Este recorrido, desde Laravel hasta los planes de microservicios, refleja una evolución natural en la forma de pensar la arquitectura. Cada patrón tiene su momento y su propósito. Lo que he aprendido es que la práctica consolida la teoría, y que reflexionar sobre cuándo aplicar cada enfoque es tan valioso como dominar la técnica.