🧱 ¿Qué es un Bounded Context?
Un Bounded Context es una frontera semántica dentro del dominio, donde un modelo tiene significado claro y consistente. Dentro de esa frontera, los términos, reglas y estructuras son estables y bien definidos.
🔹 Ejemplo en comercio exterior:
- En el contexto de Pagos Internacionales, “Liquidación” puede significar algo distinto que en Gestión Aduanera.
- Cada contexto tiene su propio modelo, base de datos, API y equipo responsable.
🗺️ ¿Qué es un Context Map?
Un Context Map es una representación visual y semántica de cómo los Bounded Contexts se relacionan entre sí. Define los tipos de integración, dependencia y colaboración entre contextos.
🔹 Tipos de relaciones en un Context Map:
🧠 ¿Cómo usar Bounded Contexts para dividir microservicios?
- Identifica subdominios funcionales
- Usa Event Storming para descubrir eventos clave y agruparlos.
- Define límites semánticos
- ¿Dónde cambia el significado de los términos? ¿Dónde se usan reglas distintas?
- Asigna equipos por contexto
- Cada equipo gestiona su modelo, base de datos y ciclo de vida.
- Diseña APIs contractuales
- Usa OpenAPI, GraphQL o gRPC para definir contratos claros entre contextos.
- Documenta con Context Maps
- Usa diagramas C4 + relaciones semánticas para visualizar la arquitectura.
📦 Artefactos recomendados
- Context Map visual (Mermaid, Structurizr DSL)
- ADR por contexto (decisiones locales con impacto global)
- Checklist de integración (tipo de relación, contrato, resiliencia)
- Documentación viva (Markdown + diagramas + métricas)
🧩 ¿Y tú, JHON?
Con tu enfoque en gobernanza y documentación modular, podríamos armar juntos una plantilla de Context Map exportable, con ejemplos de relaciones, métricas de acoplamiento y decisiones arquitectónicas. También puedo ayudarte a estructurar un flujo de validación de contratos entre contextos usando AI y CI/CD. ¿Te gustaría avanzar en esa dirección?
🧠 ¿Cómo usar Bounded Contexts para dividir microservicios?
- Identifica subdominios funcionales
- Usa Event Storming para descubrir eventos clave y agruparlos.
- Define límites semánticos
- ¿Dónde cambia el significado de los términos? ¿Dónde se usan reglas distintas?
- Asigna equipos por contexto
- Cada equipo gestiona su modelo, base de datos y ciclo de vida.
- Diseña APIs contractuales
- Usa OpenAPI, GraphQL o gRPC para definir contratos claros entre contextos.
- Documenta con Context Maps
- Usa diagramas C4 + relaciones semánticas para visualizar la arquitectura.
📦 Artefactos recomendados
- Context Map visual (Mermaid, Structurizr DSL)
- ADR por contexto (decisiones locales con impacto global)
- Checklist de integración (tipo de relación, contrato, resiliencia)
- Documentación viva (Markdown + diagramas + métricas)
🧩 Perspectiva aplicada: diseño de microservicios con patrones DDD
🔹 1. Inicio con Event Storming
En proyectos complejos (como comercio exterior o fintech), se comienza con sesiones de Event Storming para identificar eventos clave del negocio. Esto permite descubrir Bounded Contexts de forma natural, sin imponer una estructura técnica prematura.
Ejemplo: “Factura emitida”, “Contenedor inspeccionado”, “Pago confirmado” → se agrupan en contextos como Facturación, Logística, Pagos Internacionales.
🔹 2. Context Maps para definir relaciones
Una vez definidos los contextos, se documentan sus interacciones usando Context Maps. Esto ayuda a decidir si se necesita un Anticorruption Layer, una relación Conformist, o una Open Host Service.
En una implementación real, el sistema de pagos externos se integró como Conformist, mientras que el ERP interno usó un Anticorruption Layer para evitar contaminación semántica.
🔹 3. Microservicios alineados a Bounded Contexts
Cada contexto se convierte en un microservicio con su propio modelo, base de datos y ciclo de vida. Se definen contratos API claros (OpenAPI, gRPC) y se versionan junto con el código.
Se usó ADR para registrar decisiones como “usar PostgreSQL en logística por compatibilidad con GIS” o “exponer cotizaciones como GraphQL para flexibilidad”.
🔹 4. Evolución con Strangler Fig
En sistemas legacy, se aplicó el patrón Strangler Fig para migrar funcionalidades críticas sin interrumpir la operación. Se interceptaron llamadas en el gateway y se redirigieron gradualmente a nuevos servicios.
Esto permitió validar cada nuevo módulo con métricas como porcentaje de tráfico redirigido, errores por endpoint, y code churn.
🔹 5. Gobernanza distribuida con validación automática
Se integraron linters, pruebas contractuales (Pact), y validación de convenciones en CI/CD. Esto permitió que cada equipo tuviera autonomía sin perder coherencia global.
Se usó una matriz de gobernanza técnica con criterios como SRP, acoplamiento, frecuencia de cambio, y volatilidad de decisiones.
🧠 ¿Cómo mejorar la integración y evolución?
- Documentación viva: Markdown + diagramas como código + ADRs versionados.
- Flujos de validación con AI: para detectar violaciones arquitectónicas y sugerir refactorizaciones.
- Dashboards ejecutivos: para mostrar métricas de evolución, estabilidad y rendimiento por contexto.
- Plantillas compartidas: para decisiones, contratos, métricas y documentación técnica.
