¿Cómo te ayudan los bounded contexts de domain-driven design a trazar correctamente los límites de tus microservicios?

#Por qué "un microservicio por tabla" fracasa

El error más común al descomponer un monolito es trazar los límites de los servicios alrededor de tablas de base de datos, o alrededor de qué equipo resulta dueño de cierto código, sin preguntarse qué significa realmente ese límite. El resultado es un monolito distribuido: servicios que son procesos físicamente separados pero semánticamente inseparables, llamándose entre sí de forma síncrona en cadenas largas porque ningún servicio realmente posee una porción coherente del negocio. El bounded context de domain-driven design es la herramienta que arregla esto, porque traza límites alrededor del significado, no de la infraestructura.

#Qué es realmente un bounded context

Un bounded context es un límite explícito dentro del cual un modelo de dominio —sus entidades, sus reglas, su vocabulario— es internamente consistente, y fuera del cual las mismas palabras pueden significar algo completamente distinto. Piensa en la palabra "Cliente" en una empresa de e-commerce. En el contexto de Ventas, un Cliente tiene una fuente de lead, una etapa de negociación y un puntaje de valor de vida. En el contexto de Soporte, esa misma persona se describe por su historial de tickets, su nivel de SLA y sus calificaciones de satisfacción. En el contexto de Envíos, es poco más que una dirección de entrega y un conjunto de preferencias. No son tres vistas imperfectas de un único Cliente "verdadero": son tres modelos legítimamente distintos, cada uno correcto dentro de su propio contexto, y forzarlos dentro de una sola entidad Cliente compartida es exactamente el tipo de acoplamiento de objeto-dios que hace imposible cambiar los servicios de forma independiente.

#Lenguaje ubicuo

Dentro de un bounded context, el equipo —ingenieros y expertos de dominio juntos— acuerda un vocabulario único e inequívoco, el lenguaje ubicuo, y ese vocabulario aparece literalmente en el código: nombres de clases, nombres de métodos, nombres de eventos. La disciplina no es "elige buenos nombres", es "el código y la conversación de negocio usan exactamente las mismas palabras", de modo que un experto de dominio pueda leer la firma de un método y reconocer su propio proceso. Cuando encuentras la misma palabra usada por dos grupos de personas para significar dos cosas distintas, has encontrado un límite de contexto, aunque nadie lo haya dibujado todavía en un diagrama de arquitectura.

#Mapeo de contextos: cómo se relacionan los bounded contexts entre sí

Los bounded contexts no existen de forma aislada: necesitan integrarse, y los patrones de mapeo de contexto de DDD describen el tipo de relación, que es exactamente el vocabulario que un entrevistador quiere escuchar:

• Shared Kernel (núcleo compartido) — dos contextos comparten deliberadamente un subconjunto pequeño y cuidadosamente gobernado del modelo (típicamente una librería de value objects centrales, como Dinero o Dirección). Es acoplamiento alto por diseño: cualquier cambio al núcleo compartido requiere coordinar a ambos equipos, así que debe mantenerse lo más pequeño posible.
• Customer-Supplier (cliente-proveedor) — un contexto (el proveedor) produce algo de lo que depende el otro (el cliente), y ambos equipos negocian juntos el roadmap y la interfaz del proveedor, con influencia real por parte del cliente.
• Conformist (conformista) — parecido a cliente-proveedor, pero el equipo downstream no tiene poder de negociación (a menudo porque el upstream es un proveedor externo grande o el sistema legacy de otra organización), así que simplemente se adapta al modelo que el upstream ofrezca.
• Anti-Corruption Layer (capa anticorrupción, ACL) — el equipo downstream construye una capa de traducción explícita que convierte el modelo upstream en su propio modelo interno, de forma que un modelo legacy, externo o desordenado nunca filtre su forma hacia la lógica de dominio central del servicio downstream. Es el patrón más útil para integrarse con sistemas legacy o proveedores externos.
• Open Host Service / Published Language (servicio anfitrión abierto / lenguaje publicado) — un contexto expone un contrato público bien documentado, estable y versionado, pensado para muchos consumidores, así cada integración nueva no requiere una negociación a medida.
• Partnership (asociación) — dos equipos evolucionan dos contextos juntos con dependencia mutua negociada y coordinación estrecha, típicamente porque sus roadmaps están inherentemente ligados.
• Separate Ways (caminos separados) — la decisión deliberada de no integrarse, incluso duplicando una pequeña porción de funcionalidad en ambos contextos, porque el costo de acoplamiento de integrar superaría el costo de la duplicación.

#Encontrando los límites en la práctica

La técnica práctica que más equipos usan es el event storming: reunir a expertos de dominio e ingenieros en una sala y mapear en notas adhesivas, en el orden en que ocurren, los eventos de dominio significativos de todo el proceso de negocio —PedidoCreado, PagoAutorizado, InventarioReservado, EnvíoDespachado—. Aparecen costuras naturales donde cambia el vocabulario, donde un grupo de interesados deja de importarle los detalles y empieza la experticia de otro grupo, o donde el ritmo de cambio o las necesidades de escalado difieren fuertemente. Esas costuras son tus bounded contexts y, por extensión, candidatos sólidos para límites de microservicio, no porque un diagrama lo indicara, sino porque dividir ahí produce servicios que un equipo pequeño puede entender, cambiar y desplegar sin tener que renegociar el significado de una entidad compartida cada vez.

#Por qué esto le gana a una descomposición basada en diagramas ER

Una descomposición entidad-relación clásica optimiza para eliminar la duplicación de datos en toda la empresa: una única tabla Cliente verdadera, normalizada, referenciada en todas partes. La descomposición por bounded context optimiza algo completamente distinto: la autonomía de los equipos y la propiedad clara de una capacidad de negocio, y acepta explícitamente algo de duplicación (una proyección desnormalizada de dirección de envío del cliente dentro del contexto de Envíos, mantenida eventualmente consistente vía eventos) como el precio de esa autonomía. Ese intercambio —duplicación a cambio de capacidad de despliegue independiente— es la idea central que un entrevistador está evaluando con esta pregunta.