He visto esto repetirse decenas de veces.
Un equipo construye una API con patrones inconsistentes. El controlador A valida con una clase propia. El B valida en línea. El C hace un híbrido. Los formatos de respuesta varían. Los errores son inconsistentes. Los nombres de campo derivan.
Seis meses después, la base de código se convierte en arqueología. Las revisiones se alargan porque no hay una referencia. Cada funcionalidad nueva tarda el doble porque estás peleando con el código en lugar de extenderlo.
O peor: un equipo gana el debate sobre «arquitectura correcta» el primer día. Implementan CQRS. O event sourcing. O microservicios. Cero usuarios. Cero problemas. Pero ahora cada funcionalidad exige atravesar cinco capas antes de escribir lógica de negocio. La velocidad se desploma de inmediato. La arquitectura que iba a «preparar el sistema para el futuro» se convierte en lo que impide publicar. Ambos fracasos comparten la misma enfermedad: inconsistencia y complejidad prematura.
Cómo aprendí esto
Pasé tres años en una empresa construyendo una API que empezó preciosa. El primer endpoint era perfecto. Teníamos un patrón. Todo el mundo lo entendía. Luego contratamos a dos desarrolladores más.
Uno se saltó los resources y devolvía arrays en crudo. Otro validaba en línea porque los FormRequests le parecían «demasiado abstractos». Alguien quería DTOs en todas partes por «seguridad de tipos», lo que derivó en formas de respuesta distintas. Otro envolvió Eloquent en repositorios «por si cambiamos de base de datos».
Nadie estaba equivocado. Cada decisión tenía sentido por sí sola.
En conjunto, construimos una API donde no podías leer dos endpoints y entender el tercero. Cada funcionalidad nueva empezaba con «¿cómo lo hicimos la última vez?», y la respuesta cambiaba cada vez. Un endpoint cacheaba agresivamente. Otro no cacheaba nada. Uno devolvía códigos de estado correctos; otro enterraba los errores dentro de respuestas 200.
Para el mes seis no publicábamos: hacíamos análisis forense. Añadir un endpoint costaba tres días en lugar de tres horas. Las revisiones se convertían en debates de arquitectura. La gente junior se ralentizaba porque tenía que aprender cuarenta y siete patrones distintos en lugar de uno.
Pull requests que deberían haber tardado una hora se quedaban días. No porque la lógica estuviera mal, sino porque cada endpoint desataba una discusión nueva. Y ninguna discusión se resolvía nunca, porque no teníamos cimientos, sólo precedentes contradictorios.
Recuerdo una reunión diaria en la que el equipo entero estaba bloqueado. No en funcionalidades: en entender el código del anterior. Estábamos gastando tiempo de ingeniería descifrando inconsistencia en lugar de resolver problemas.
Lo irónico es que no teníamos problemas de rendimiento ni de escalado. La «arquitectura flexible» que creíamos estar construyendo se convirtió en lo más inflexible posible. No podías cambiar nada porque nadie entendía por qué estaba hecho así.
Acabamos reescribiendo la API, no porque estuviera rota, sino porque la consistencia se había desmoronado. La reescritura llevó seis semanas porque las reglas no estaban claras.
La segunda vez elegimos un patrón. FormRequests para validar. DTOs para datos tipados. Resources para respuestas. Una estructura de error. Un Response Wrapper. Sin excepciones. Sin «este endpoint es especial».
Debatimos una vez, nos comprometimos y seguimos adelante.
La diferencia fue de la noche al día. La velocidad no sólo volvió: se compuso. Cuando no estás averiguando cómo hacer algo, estás resolviendo el problema de negocio de verdad.
Desde entonces he usado este mismo patrón en varias APIs en producción, y el resultado ha sido siempre el mismo: claridad primero, velocidad después, escala al final.
Años más tarde, la misma lista sigue valiendo: usa las funcionalidades que Laravel ya trae, borra antes de añadir y mantén la solución aburrida.
Por eso existe este libro. No porque haya encontrado «la mejor manera», sino porque viví lo que pasa cuando no decides por adelantado, y vi lo que desbloqueaba la consistencia.