Durante años, escalar en Java obligaba a elegir entre código legible y código que aguantara la carga. Los virtual threads cambiaron esa ecuación. Repasamos el modelo clásico, la salida reactiva, lo que Java 25 añadió con Scoped Values y concurrencia estructurada, y cuándo conviene usar corrutinas de Kotlin o promesas funcionales.

El Patrón State convierte las reglas de negocio implícitas en comportamiento explícito. Cada estado sabe exactamente qué puede y qué no puede hacer. Cuando el negocio agrega un nuevo estado del ciclo de vida, creas una clase nueva con sus propias reglas — las existentes no se tocan.

El Patrón Observer invierte el control — en vez de que el service empuje lógica hacia afuera, los interesados se suscriben y reaccionan por su cuenta. Agregar una nueva reacción al cambio de stock es crear una clase nueva, no editar la existente.

La Facade es el caso de uso hecho clase. Cuando un endpoint empieza a coordinar cinco servicios en orden, con validaciones intermedias, esa lógica no pertenece al controller. Pertenece a la Facade, donde el flujo es legible y los cambios de negocio tienen un solo lugar al que ir.

El Patrón Adapter es la capa de traducción entre tu sistema y los SDKs externos. Twilio, SendGrid, Firebase — cada uno habla su idioma. El adapter los hace hablar el tuyo. Si el proveedor cambia, solo cambia el adapter. El service y el controller no se enteran.

El patrón Strategy convierte un if/else que nadie quiere tocar en una lista de clases donde cada una sabe exactamente qué puede hacer. Con Spring Boot, agregar un proveedor nuevo es crear un archivo nuevo, sin editar nada que ya funciona.