No necesitás microservicios. Necesitás límites claros.

La mayoría de los equipos que adoptan microservicios lo hacen demasiado pronto. Y lo sé porque lo hice.

El síntoma típico: el monolito empieza a doler. Los deploys tardan. Los conflictos de merge son frecuentes. Alguien propone "partirlo en servicios" y de repente todos están de acuerdo porque suena a solución.

Pero no es una solución. Es un cambio de problema.

El error de fondo

Cuando partís un monolito mal estructurado en microservicios, lo que hacés es distribuir el acoplamiento. Antes tenías un módulo que llamaba directamente a otro. Ahora tenés un servicio que llama a otro por HTTP. El acoplamiento sigue ahí — solo que ahora falla en producción en lugar de en tiempo de compilación.

Los microservicios no resuelven el problema de los límites difusos. Los agravan.

Qué son los límites reales

Un límite bien definido es aquel que encapsula un concepto de negocio completo. No una tabla de base de datos, no una entidad técnica — un dominio funcional con sus propias reglas, su propio lenguaje, su propio ciclo de vida.

Si tenés un sistema de e-commerce, Pedidos y Inventario son límites candidatos. RepositorioDePedidos no lo es.

La diferencia importa porque:

• Un límite real puede existir como módulo dentro de un monolito y funcionar perfectamente
• Un límite real puede eventualmente convertirse en un servicio independiente, si el equipo y el tráfico lo justifican
• Un límite mal definido va a sangrar por las costuras sin importar la arquitectura que uses

El camino correcto

Primero, definí los límites. Usá Domain-Driven Design como lente conceptual, no como receta de implementación. Identificá los bounded contexts, los ubiquitous languages, las fricciones reales entre equipos.

Después, implementá esos límites como módulos en tu monolito. Un módulo por bounded context, con una interfaz pública explícita y sin dependencias directas entre internals.

Cuando el equipo crezca o el tráfico lo justifique, extraer un módulo bien delimitado a un servicio es una tarea de un sprint. Extraer un espagueti es una saga de seis meses.

Cuándo sí tiene sentido

Los microservicios hacen sentido cuando:

• Tenés equipos independientes que necesitan deployar sin coordinarse
• Tenés cargas de trabajo con requerimientos de escala radicalmente distintos
• Tenés partes del sistema con ciclos de vida o SLAs diferentes

Si ninguna de esas condiciones aplica, el monolito modular es la arquitectura correcta. No es una arquitectura de segunda — es la arquitectura honesta para el problema que tenés.