El problema no es el tamaño del servicio
Dividir un monolito en muchos desplegables no crea una arquitectura sana. Lo que escala es el límite de responsabilidad: qué dominio posee cada equipo, qué datos son canónicos y qué contratos son públicos.
Bounded contexts en la práctica
- Nombra el dominio en lenguaje de negocio (no en nombres técnicos).
- Lista comandos y consultas que cruzan el límite.
- Decide ownership de datos: database-per-service cuando el acoplamiento lo justifique.
- Publica un contrato versionado (OpenAPI/AsyncAPI) y un changelog.
Señales de un mal límite
- Dos servicios escriben la misma tabla “por comodidad”.
- Un cambio de campo rompe tres equipos a la vez.
- Conversaciones de diseño que siempre terminan en excepciones ad hoc.
Contratos que no mienten
- Versiona APIs (
/v1, cabeceras o schemas). - Errores tipados y documentados.
- Compatibilidad hacia atrás durante una ventana clara.
- Contratos de eventos con esquema (JSON Schema / Avro / Protobuf).
Observabilidad por contexto
Cada bounded context debe exponer: latencia, errores, saturación y trazas con correlation id. Sin eso, el mapa de servicios es decoración.
La autonomía de los equipos nace de límites bien definidos, no de más repositorios.
Cuándo no usar microservicios
Equipos pequeños, dominio inestable o producto en descubrimiento suelen ganar más con un modular monolith bien modularizado. Los microservicios son un coste operativo que se paga con independencia de despliegue.
Siguiente paso
Si estás partiendo un monolito o rediseñando dominios, conviene un mapa de contextos y un plan de strangler pattern. Contacta con ingeniería.
