Bounded context y context maps en microservicios

Cuando un sistema crece, dividirlo en microservicios bien delimitados deja de ser una opción y se vuelve una necesidad. Aquí entenderás cómo usar bounded context, context maps y patrones de relación entre equipos para diseñar arquitecturas de microservicios que escalen sin convertirse en una bola de lodo. Es contenido pensado para arquitectos, desarrolladores backend y líderes técnicos que trabajan con dominios complejos como aduanas, comercio internacional o sistemas bancarios.

¿Qué son los microservicios y cómo se comparan con un equipo especializado?

Piensa en los microservicios como técnicos especializados que apoyan a un nadador de alto rendimiento. Uno se ocupa de la técnica de nado, otro de la psicología del deporte y otro más de la nutrición. Cada uno aporta valor desde su especialidad, pero deben trabajar de forma armónica para que el atleta rinda al máximo.

Esa misma lógica aplica al software. En un caso real como el del Banco Interamericano de Desarrollo, puedes tener decenas de microservicios y la primera decisión crítica es dónde establecer las particiones y las fronteras entre ellos.

¿Qué es un microservicio? Es un componente de software autónomo que cumple una responsabilidad específica del dominio y se comunica con otros servicios mediante contratos definidos. Cada uno puede desplegarse y evolucionar de forma independiente.

¿Cómo delimitar fronteras con bounded context y context maps?

En una iteración inicial puedes tener un modelo de dominio simple. Pero a medida que aparecen más casos de uso y excepciones, ese modelo se complica hasta volverse casi ilegible. Imagina un subdominio que valida licencias, patentes y certificados de origen para importaciones en un sistema de aduanas: navegarlo entero es agotador y propenso a errores [01:30].

Ahí entra el bounded context, una técnica que delimita modelos del dominio. Una entidad puede existir en varios contextos, pero se especializa dentro de cada uno según las reglas y el lenguaje de ese contexto.

Los context maps llevan esa idea un paso más allá: te permiten visualizar y dividir el problema en subdominios especializados. En el caso de aduanas, una primera división natural separa exportaciones de importaciones. Al profundizar aparecen más capas:

• Aduanas de exportación con sus entidades propias.
• Exportación y sus tributos asociados.
• Licencias, patentes y certificados como subdominio legal independiente.
• Aduanas, tributos y licencias del lado de importaciones, usualmente más complejos por la dinámica del comercio internacional.

Esta segmentación no solo organiza el código, también ordena la conversación entre equipos.

¿Qué patrones existen para relacionar contextos?

Las relaciones entre context maps se pueden modelar con patrones reconocidos. Todo suele empezar como una big ball of mud, donde los contextos están mezclados y revueltos. A partir de ahí, aplicas patrones que no siempre son técnicos: muchos describen cómo se relacionan los equipos detrás de cada servicio.

• Mutuamente dependientes: los equipos negocian constantemente cambios en los contratos de software.
• Relación libre: cada contexto evoluciona por su camino, aunque sigan conectados.
• Equipo principal y equipo cliente: uno lidera y el otro se adapta, lo que afecta velocidades de entrega y despliegues.

Definir bien esa dependencia es lo que hace productiva la relación entre equipos.

¿Cómo aplicar DRY en una arquitectura de microservicios?

El principio don't repeat yourself (DRY) busca evitar que repitas código por todo el sistema. Pero en microservicios, evitarlo al 100% es prácticamente imposible y a veces ni siquiera deseable.

Puedes repetir conscientemente modelos, lógicas e incluso servicios pequeños para mantener la independencia entre contextos. Lo que no debes hacer es llevarlo al extremo de convertir cada microservicio en un monolito independiente que contiene toda la lógica del sistema solo para evitar dependencias.

¿Cuándo es válido repetir código entre microservicios? Cuando duplicar evita acoplamientos fuertes entre contextos distintos y permite que cada equipo evolucione a su ritmo. La clave está en duplicar con intención, no por descuido.

La mejor estrategia es apoyarte en context maps y patrones de integración para mantener DRY donde tiene sentido, sin sacrificar la autonomía de cada servicio.

¿Qué retos técnicos aparecen al integrar microservicios?

Dividir el sistema trae beneficios, pero también complejidades nada triviales que debes diseñar desde el inicio:

• Latencias de red entre servicios distribuidos.
• Transacciones distribuidas que requieren patrones como saga o compensación.
• Eventos y mensajería asíncrona entre sistemas, con sus garantías de entrega y orden.

Cada uno de estos retos tiene patrones específicos que puedes aplicar, pero ignorarlos al inicio del diseño suele costar caro más adelante.

¿Cómo organizar entornos de trabajo con varios equipos en paralelo?

Cuando tienes muchos equipos trabajando al mismo tiempo, no basta con cuidar el producto: también hay que cuidar los entornos de trabajo. Aquí entran herramientas modernas como los dev containers y los test containers, entornos controlados con herramientas estandarizadas disponibles para cada equipo.

Esto te permite:

• Usar entornos compartidos en la nube en lugar de configuraciones locales frágiles.
• Ejecutar tests de integración reales, no solo unitarios aislados.
• Mantener seguridad y consistencia en el ciclo de vida del software.

La estandarización del entorno reduce fricción entre equipos y acelera la entrega sin sacrificar calidad.

¿Cómo estás dividiendo los contextos en tu arquitectura actual? Cuéntame en los comentarios qué patrón te ha funcionado mejor y dónde has visto aparecer la temida bola de lodo.