Todo lo que hay en este libro hasta ahora describe una API. Un bootstrap/app.php. Un routes/api.php. Un LicenseController hablando con un driver de Statamic detrás de una Facade. Esa es la forma correcta de construir un servicio, y si pararas aquí ya tendrías algo mejor que lo que publica la mayoría de los equipos. Pero la Webplo License API no corre sola. Corre junto a una superficie de facturación, otra de aprovisionamiento de servidores, otra de repositorios y commits, otra de contenido con IA, otra de DNS y CDN, y una aplicación de cara al cliente que tiene que hacer que todo eso parezca un solo producto a un comerciante que nunca ha oído ninguno de esos nombres y nunca debería oírlos.
Este capítulo cubre qué cambia cuando una API bien construida se convierte en una docena: la forma que adoptan esas doce entre sí, por qué exactamente una de ellas puede guardar las credenciales de cada proveedor externo, por qué el código horneado en lo que la flota genera no es lo mismo que la flota, y por qué una lectura y una escritura pueden recorrer caminos completamente distintos para llegar a los mismos datos. Una docena de buenos servicios mal dispuestos sigue siendo un mal sistema.
Que cambia con una docena de servicios
Todos los patrones que este libro ha enseñado —FormRequests, DTOs, Resources, Response Wrappers, Facades sobre Managers sobre Drivers— funcionan igual tengas un servicio o doce. Ese es el sentido de un patrón: no le importa cuántas veces lo apliques. Lo que no sobrevive al salto de uno a doce es cualquier suposición que estuvieras haciendo sobre estar solo.
Con un servicio, «llamar al proveedor» significa un cliente HTTP, un fichero de configuración, una estrategia de reintentos. Con una docena, «llamar al proveedor» es una decisión con una topología pegada: qué servicio hace esa llamada, quién más puede hacerla y qué le pasa a todos los que están aguas abajo cuando ese proveedor tiene un mal día. Puedes tener cada servicio arquitectónicamente bien y aun así acabar con una flota que se comporta de forma impredecible, porque nadie decidió cómo se relacionan entre sí. La consistencia dentro de un servicio era el argumento del capítulo 1. Este capítulo es el mismo argumento una capa más arriba: consistencia entre servicios.