Bounded Context y límites de dominio

Bounded Context (BC) es un límite claro dentro del cual actúa un solo Lenguaje Ubiquitous, modelos consistentes e invariantes. Dentro del límite, los términos son inequívocos («Apuesta», «Cliente», «Límite»), y hacia afuera, el contexto se comunica con contratos (eventos/comandos) y no tira hacia adentro de las «colas» semánticas de otros. Los límites bien seleccionados reducen la conectividad, simplifican la escala y aceleran la evolución del producto.

1) Por qué se necesitan límites

Reducción de la carga cognitiva. El equipo trabaja con un solo modelo y un solo lenguaje, no con «todo el negocio a la vez».
Aislamiento de invariantes. Las reglas críticas (equilibrio ≥ 0, unicidad de inicio de sesión) viven en un solo lugar y están protegidas por agregados.
Gestión de cambios. La evolución del esquema/reglas dentro de BC no rompe al vecino - hay contratos explícitos.
Rendimiento y fiabilidad. Dentro de BC, puede elegir un modelo de consistencia y almacenamiento adecuados; fuera - proyecciones asíncronas.

2) Cómo identificar Bounded Context

1. Storming de eventos: extrae los eventos de dominio «qué pasó», luego los comandos «qué pedimos hacer», luego los agregados «quién garantiza la regla».

2. Clústeres de lenguaje: donde las palabras y las reglas coinciden de manera constante - potencial BC. Donde la palabra «Cliente» significa diferente (pagador vs jugador) - hay contextos claramente diferentes.

3. Invariantes y ownership: ¿qué no se puede violar y quién responde? El invariante → dentro de ese CC que puede garantizarlo.

4. Flujo de valor: agrupar los pasos que cambian a menudo juntos - son candidatos a un solo BC.

5. Org-estructure: si una parte hace un comando separado con KPI separados, probablemente sea un BC separado (pero no al revés: la estructura orgánica no debe dictar ciegamente el modelo).

• La disputa sobre los términos («apuesta», «billete», «ronda» son diferentes significados).
• El invariante más caliente «fluye» a través de los servicios.
• Diferentes SLO y ritmo de cambio.
• «Dual-write» entre módulos en aras de la atomicidad.

3) Contextos típicos (ejemplo de área de tema)

Identidad/KYC - Registro, niveles de verificación, estados de restricción.
Wallet/Ledger - balances, cableado, reservas, monedas.
Betting/Orders - recepción, cotizaciones, cálculo.
Game/Round - ciclo de vida de la ronda, resultados.
Bonus/Promo - devengo, vager, conversión.
Pagos - depósitos/retiros, estados de pasarelas de pago.
Compliance/Reporting - informes, auditorías, escaparates regulatorios.
Catalog/Provider Integration - juegos, versiones, estados de proveedores.
Analytics/Read Models - proyecciones y representaciones materializadas.

4) Context Map: cómo interactúan los BC

• Customer–Supplier. Un BC (Proveedor) suministra eventos/datos, el otro (Cliente) ajusta sus modelos.
• Conformist. El cliente adopta el lenguaje y el modelo de proveedor tal como están (por ejemplo, un registro reglamentario).
• Partnership. Dos BC evolucionan sincrónicamente el lenguaje y los contratos (a menudo un comando/roadmap).
• Shared Kernel. Elevación mínima total/biblioteca, versionada conjuntamente; usar con precaución.
• Anti-Corruption Layer (ACL). Capa protectora que traduce modelos ajenos a su lenguaje.
• Open Host Service / Published Language. Protocolos/esquemas públicos versionados y documentados.

Práctica: de forma predeterminada, utilice ACL y eventos asíncronos; Conformist - sólo si el proveedor dicta el estándar, Kernel compartido - es mínimo y consciente.

5) Límite = idioma + modelo + invariantes + almacenamiento

• Ubiquitous Language. Diccionario de términos con ejemplos.
• Agregados e invariantes. Quién «mantiene» las reglas y qué operaciones están permitidas.
• Modelo de coherencia. Strong/CP para dinero, EC/causal para escaparates.
• Almacenamiento e índices. Se seleccionan bajo invariantes y SLO.
• Contratos de salida. Eventos/comandos, versiones de esquemas, SLO de entrega.

Exterior: sin dependencias SQL/Tabular directas. La comunicación es a través del contrato.

6) Fronteras y coherencia (PACELC)

Dentro de BC: seleccione el modelo bajo invariantes (Wallet - Strong, Betting - Strong en la recepción).
Entre BC: más a menudo eventual a través de eventos y proyecciones. Si necesita un chequeo sincrónico, un comando explícito con un depline y un error si no está disponible (no una llamada «oculta» de NAT).

7) Capa anticorrupción (ACL)

Tarea ACL: no permitir que el idioma de otra persona y los datos «sucios» dentro de BC.

Esquemas de mapeo: externo 'PaymentStatus = SETTLED' → interno 'LedgerEntry (type = Credit, reason = PsPSettle)'.
Validación y enriquecimiento: verificación de invariantes, normalización de temporizones, monedas.
Versioning: compatibilidad con 'schema _ version' contrato externo, compatibilidad inversa.
Idempotencia: por 'external _ id '/' operation _ id'.
Observabilidad: etiquetas de 'source', 'schema _ version', 'mapping _ id', DLQ para mensajes 'venenosos'.

8) Límites y datos: propiedad, proyecciones, API

Ownership: ¿Quién posee la «verdad»? Sólo el propietario cambia el registro. El resto de BC son modelos de lectura y enlaces.
Proyecciones: tablas desnormalizadas bajo lecturas; se actualizan a partir de los eventos.
API: comandos (mutar en el propietario) y consultas (leer proyecciones). No hay apdates «de extremo a extremo» de los datos de otras personas.

9) Evolución y versiones

Eventos y API: con 'schema _ version' y política de compatibilidad (additive + fallback).
Azul/Verde por BC: el nuevo contrato 'v2' se publica en paralelo al 'v1', el tráfico se traslada progresivamente.
Migraciones: para cambios importantes - nueva proyección/servicio, «switch bifásico» de lecturas.

10) Pruebas de límites

Pruebas de contrato: verificar que BC cumple con el contrato publicado (pruebas de producto) y entiende correctamente el extranjero (pruebas de consumo).
Property-based: invariantes de agregados dentro de BC (equilibrio, límites, singularidades).
Chaos en integraciones: retardos, fuera de orden, duplicados, schema-evolution; tener DLQ y un redrive seguro.
Pruebas NFR: p95/carga máxima en la frontera (servidor de eventos/ACL).

11) Observabilidad y SLO a lo largo de los límites

Métricas: a través de eventos/comandos, 'projection _ lag _ ms',' dlq _ rate ', errores de mapping, p95 API.
Treking: etiquetas obligatorias 'bc', 'tenant _ id', 'event _ id', 'operation _ id', 'schema _ version'.
Alertas: superación de la laguna de proyecciones, crecimiento de fallos de comandos, esquema «flap» (mucho 'schema _ mismatch').

12) Multi-tenant y regiones

'tenant _ id' está en las claves de todos los eventos y proyecciones en la frontera.
Fairness: límites a publicaciones/redrive per tenant para que el «ruidoso» no arruine el SLO de los vecinos.
Residencia: los datos de BC viven en una región «doméstica»; entre regiones - agregados/informes.

13) Anti-patrones (a lo que conduce la frontera borrosa)

Un gigantesco «servicio de núcleo». Todo en un solo lugar → lucha por transacciones, lanzamientos largos, baja autonomía.
Integraciones tabulares. SELECCIÓN directa en tablas ajenas → fragilidad y coupling en el esquema.
Dual-write. Al mismo tiempo escribir en dos BC «por conveniencia» → discrepancias y sabotaje de invariantes.
Conformist predeterminado. «Adoptaron el modelo de otra persona tal como es» → la fuga de significados ajenos, la imposibilidad de la evolución.
Llamadas sincrónicas ocultas. La llamada de NAT «en algún lugar del interior» sin contrato explícito y sin línea → una dependencia inesperada en cuanto a disponibilidad.

14) Ejemplo de contornos (esquema verbal)

[Wallet/Ledger] <--CP, Leader, Transactions-->
publishes: WalletReserved/Committed v
[Betting] <--CP on bid taking-->
events: BetPlaced/Settled v
[Read Models/Analytics] <--EC projection-->

[Payments] --ACL--> [Wallet/Ledger]
[Provider Integration] --ACL--> [Game/Round]
[Compliance] <-events - [KYC/Identity], -> reports [Reporting]

15) Mini-Hyde para elegir la frontera

1. Articular invariantes y determinar quién puede garantizarlos.
2. Describa el diccionario (10-20 términos) y compruebe que el comando tiene una comprensión.
3. Dibuja Context Map y los tipos de relación.
4. Decida el modelo de consistencia dentro y en las juntas.
5. Diseñe contratos (eventos/comandos) y ACL.
6. Planifique la observabilidad (métricas/treysing/alertas) y DLQ/redrive.
7. Lleve a cabo pruebas de contrato y «tormenta» (chaos) para las integraciones.
8. Asegúrese de que el gobierno: quién habla el idioma/esquema, cómo se realizan los cambios.

16) Lista de verificación antes de la venta

• Cada BC tiene un diccionario, agregados e invariantes.
• Se definen las relaciones en Context Map y se documentan los contratos.
• Integraciones a través de eventos/comandos y ACL, no hay dependencias SQL directas.
• Idempotencia de comandos/eventos; hay outbox/inbox y DLQ.
• Modelo de consistencia (dentro/entre BC) fijado y probado.
• Versificación de esquemas y estrategia de compatibilidad (v1/v2).
• Las métricas/errores/rendimiento y alertas están configuradas.
• Se respetan las políticas de multi-tenencia y data-residency.
• Playbucks operativos: schema-mismatch, redrive, rebuild proyecciones.

17) Recetas rápidas

Dinero y límites: BC independiente con CP y transacciones, API sólo comandos, eventos como resultado de la verdad para las lecturas.
Fides/directorios: BC con EC, proyecciones y caché, explícito 'freshness'.
Integraciones con proveedores externos: siempre a través de ACL, eventos/comandos, versionamiento de esquemas.
Crecimiento del equipo: un BC es un equipo, el equipo tiene un «propietario del idioma» y un «guardián de invariantes».
Refactorización del monolito: primero contratos y ACL, luego separación física.

la Conclusión

Bounded Context no es sólo un diagrama, sino un contrato de trabajo sobre el lenguaje, las reglas y el modo de evolución. Los límites claros reducen la conectividad, aceleran los cambios y hacen que el sistema sea predecible en funcionamiento. Divida por sentido e invariantes, proteja los límites de la ACL y los contratos, mida todo con métricas, y su arquitectura seguirá siendo flexible y confiable, incluso con el rápido crecimiento del dominio y el equipo.