@evolith/core-domain 1.0.1 → 1.0.2

package/rulesets/topologies/event-driven/mcp/mcp-manifest.json

@@ -1,68 +0,0 @@
-{
-  "protocolVersion": "2025-03-26",
-  "topologyId": "event-driven",
-  "description": "MCP interface for the Event-Driven topology. Provides tools for inspecting and validating event-driven configurations, resources for manifest and ruleset access, and prompts for event-governed implementation guidance.",
-  "capabilities": {
-    "tools": {},
-    "resources": {},
-    "prompts": {}
-  },
-  "tools": [
-    {
-      "name": "evolith-topology-inspect",
-      "description": "Inspect an Event-Driven topology configuration and return its parsed manifest, event channels, and corpus artifact references.",
-      "inputSchema": {
-        "type": "object",
-        "properties": {
-          "configPath": {
-            "type": "string",
-            "description": "Path to the Event-Driven configuration file"
-          },
-          "includeChannels": {
-            "type": "boolean",
-            "description": "Include event channel and subscription metadata"
-          }
-        },
-        "required": ["configPath"]
-      }
-    },
-    {
-      "name": "evolith-topology-validate",
-      "description": "Validate an Event-Driven configuration against the topology ruleset and OPA policies, returning pass/fail per gate.",
-      "inputSchema": {
-        "type": "object",
-        "properties": {
-          "configPath": {
-            "type": "string",
-            "description": "Path to the Event-Driven configuration to validate"
-          },
-          "strictMode": {
-            "type": "boolean",
-            "description": "Fail on warnings, not just errors"
-          }
-        },
-        "required": ["configPath"]
-      }
-    }
-  ],
-  "resources": [
-    {
-      "uri": "evolith://topologies/event-driven/manifest",
-      "name": "Event-Driven Topology Manifest",
-      "description": "Full topology manifest for Event-Driven, including metadata, artifact references, and corpus configuration.",
-      "mimeType": "application/json"
-    },
-    {
-      "uri": "evolith://topologies/event-driven/rulesets",
-      "name": "Event-Driven Rulesets",
-      "description": "All ruleset files for Event-Driven: native rules JSON, OPA Rego policies, and WASM bundle.",
-      "mimeType": "application/json"
-    }
-  ],
-  "prompts": [
-    {
-      "name": "topology-aware-implementation",
-      "description": "Guides AI-assisted implementation to respect Event-Driven topology constraints, message ordering, idempotency, and eventual consistency."
-    }
-  ]
-}

package/rulesets/topologies/event-driven/openapi/openapi.yaml

@@ -1,186 +0,0 @@
-openapi: "3.1.0"
-info:
-  title: "Event-Driven Topology — Core API Surface"
-  version: "0.1.0"
-  description: >
-    REST API surface specific to the Event-Driven topology.
-    Describes endpoints exposed by the Core API for querying,
-    inspecting, and validating Event-Driven topology instances.
-servers:
-  - url: "https://api.evolith.dev/v1"
-    description: "Evolith Core API (production)"
-paths:
-  /topologies/{id}:
-    get:
-      tags: [Topologies]
-      summary: "Retrieve Event-Driven topology information"
-      description: >
-        Returns the full topology record for Event-Driven, including
-        dimension, status, version, governance metadata, and corpus
-        artifact references (rulesets, OPA policies, ADRs, guidance).
-      operationId: "getEventDrivenTopology"
-      parameters:
-        - name: id
-          in: path
-          required: true
-          schema:
-            type: string
-            pattern: "^event-driven$"
-            example: "event-driven"
-      responses:
-        "200":
-          description: "Successful response with Event-Driven topology data"
-          content:
-            application/json:
-              schema:
-                $ref: "#/components/schemas/EnvelopeTopology"
-        "404":
-          description: "Topology not found"
-  /topologies/{id}/manifest:
-    get:
-      tags: [Topologies]
-      summary: "Get Event-Driven topology manifest"
-      description: >
-        Returns the full topology manifest for Event-Driven, with
-        artifact references, corpus configuration, and business
-        boundary declaration.
-      operationId: "getEventDrivenManifest"
-      parameters:
-        - name: id
-          in: path
-          required: true
-          schema:
-            type: string
-            pattern: "^event-driven$"
-      responses:
-        "200":
-          description: "Successful response with Event-Driven manifest"
-          content:
-            application/json:
-              schema:
-                $ref: "#/components/schemas/EnvelopeManifest"
-  /topologies/{id}/validate:
-    post:
-      tags: [Topologies]
-      summary: "Validate Event-Driven topology rules"
-      description: >
-        Executes all applicable rulesets and OPA policies for Event-Driven
-        against a submitted configuration, returning pass/fail per gate.
-      operationId: "validateEventDrivenTopology"
-      parameters:
-        - name: id
-          in: path
-          required: true
-          schema:
-            type: string
-            pattern: "^event-driven$"
-      requestBody:
-        required: true
-        content:
-          application/json:
-            schema:
-              $ref: "#/components/schemas/ValidationRequest"
-      responses:
-        "200":
-          description: "Validation results"
-          content:
-            application/json:
-              schema:
-                $ref: "#/components/schemas/EnvelopeValidation"
-components:
-  schemas:
-    Envelope:
-      type: object
-      properties:
-        success:
-          type: boolean
-        data: {}
-        meta:
-          type: object
-          properties:
-            context:
-              type: string
-            timing:
-              type: number
-            schemaVersion:
-              type: string
-              pattern: "^\\d+\\.\\d+\\.\\d+$"
-          required: [context, timing, schemaVersion]
-      required: [success, data, meta]
-    EnvelopeTopology:
-      allOf:
-        - $ref: "#/components/schemas/Envelope"
-        - type: object
-          properties:
-            data:
-              $ref: "#/components/schemas/TopologyRecord"
-    EnvelopeManifest:
-      allOf:
-        - $ref: "#/components/schemas/Envelope"
-        - type: object
-          properties:
-            data:
-              $ref: "#/components/schemas/TopologyManifest"
-    EnvelopeValidation:
-      allOf:
-        - $ref: "#/components/schemas/Envelope"
-        - type: object
-          properties:
-            data:
-              $ref: "#/components/schemas/ValidationResult"
-    TopologyRecord:
-      type: object
-      properties:
-        id:
-          type: string
-          example: "event-driven"
-        name:
-          type: string
-          example: "Event-Driven"
-        dimension:
-          type: string
-          example: "integration"
-        status:
-          type: string
-          enum: [accepted, draft, deprecated]
-        version:
-          type: string
-          example: "0.1.0"
-    TopologyManifest:
-      type: object
-      properties:
-        apiVersion:
-          type: string
-          example: "evolith.dev/topology/v1"
-        kind:
-          type: string
-          example: "TopologyManifest"
-        metadata:
-          type: object
-        spec:
-          type: object
-    ValidationRequest:
-      type: object
-      properties:
-        config:
-          type: object
-          description: "Configuration to validate against topology rules"
-      required: [config]
-    ValidationResult:
-      type: object
-      properties:
-        passed:
-          type: boolean
-        gates:
-          type: array
-          items:
-            type: object
-            properties:
-              gate:
-                type: string
-              passed:
-                type: boolean
-              evidence:
-                type: array
-                items:
-                  type: string

package/rulesets/topologies/event-driven/operations.es.md

@@ -1,67 +0,0 @@
-# Guía de Operaciones Orientada a Eventos
-
-> **Navegación Bilingüe:** [English](./operations.md) | [Español](./operations.es.md)
-
-**Propietario:** Junta de Arquitectura
-**Topología:** Orientada a Eventos
-
-## Propósito
-
-Definir procedimientos operativos para la gestión de brokers de eventos, el monitoreo de retraso de consumidores, el manejo de colas de letras muertas (DLQ), la observabilidad del flujo de eventos y la gestión de particiones en arquitecturas orientadas a eventos.
-
-## Gestión del Broker
-
-### Monitoreo de Salud
-
-- Rastrear tiempo de actividad del broker, conteo de conexiones y throughput por tema.
-- Configurar verificaciones de salud en probes de disponibilidad y vitalidad del broker.
-- Alertar cuando el uso de memoria del broker exceda el 80% de la capacidad asignada.
-
-### Planificación de Capacidad
-
-- Monitorear el conteo de particiones del tema contra el paralelismo del consumidor.
-- Escalar nodos del broker cuando el throughput sostenido exceda el 70% de la capacidad pico.
-- Revisar configuraciones de retención trimestralmente para alinear con presupuestos de almacenamiento.
-
-## Monitoreo de Retraso de Consumidores
-
-- Exponer métricas de retraso del consumidor mediante herramientas nativas del broker (por ejemplo, Consumer Groups de Kafka).
-- Configurar umbrales de alerta: advertencia a 10,000 mensajes, crítico a 100,000 mensajes de retraso.
-- Rastrear tendencias de retraso semanalmente; investigar crecimiento persistente del retraso.
-
-## Manejo de Cola de Letras Muertas (DLQ) — ED-R03
-
-- Enviar mensajes no procesables a DLQ después del agotamiento configurable de reintentos (predeterminado: 3 intentos).
-- Monitorear la profundidad de DLQ diariamente; mensajes mayores a 72 horas requieren triaje manual.
-- Implementar herramientas de reproducción de DLQ con protecciones de idempotencia antes de reprocesar.
-
-## Observabilidad del Flujo de Eventos — ED-R08
-
-- Instrumentar productores y consumidores con tracing distribuido (OpenTelemetry).
-- Capturar metadatos del evento: tema, partición, offset, timestamp, ID del productor.
-- Mantener paneles de control del flujo de eventos mostrando tasas de producción/consumo, tasas de error y latencia de extremo a extremo.
-
-## Gestión de Particiones — ED-R04
-
-- Diseñar claves de partición para garantizar ordenamiento donde sea necesario.
-- Evitar particiones calientes distribuyendo claves en dominios de alta cardinalidad.
-- Monitorear throughput por partición; rebalancear cuando la varianza exceda 3x entre particiones.
-
-## Aplicabilidad Componible
-
-| Componible | Orientación |
-|---|---|
-| Monolito Modular | Broker embebido; la gestión de particiones es intra-proceso. |
-| Módulos Distribuidos | Cluster de broker compartido; se requiere monitoreo de retraso de consumidores entre módulos. |
-| Microservicios | Infraestructura completa de broker; aislamiento de grupo de consumidores por servicio. |
-| Serverless | Servicios de broker gestionados; el escalado de particiones lo maneja el proveedor. |
-| Computación Edge | Instancias de broker locales con sincronización periódica a la nube. |
-
-## Referencias ADR
-
-- **ADR-0015**: Infraestructura de broker de eventos y estrategia de particionamiento.
-- **ADR-0079**: Estándares de observabilidad y monitoreo de eventos.
-
----
-
-[Volver al Perfil Orientado a Eventos](./README.es.md)

package/rulesets/topologies/event-driven/operations.md

@@ -1,67 +0,0 @@
-# Event-Driven — Operations Guide
-
-> **Bilingual Navigation:** [English](./operations.md) | [Español](./operations.es.md)
-
-**Owner:** Architecture Board
-**Topology:** Event-Driven
-
-## Purpose
-
-Define operational procedures for managing event brokers, monitoring consumer lag, handling dead-letter queues (DLQs), ensuring event flow observability, and managing partitions in event-driven architectures.
-
-## Broker Management
-
-### Health Monitoring
-
-- Track broker uptime, connection count, and message throughput per topic.
-- Configure health checks on broker readiness and liveness probes.
-- Alert on broker memory usage exceeding 80% of allocated capacity.
-
-### Capacity Planning
-
-- Monitor topic partition count against consumer parallelism.
-- Scale broker nodes when sustained throughput exceeds 70% of peak capacity.
-- Review retention settings quarterly to align with storage budgets.
-
-## Consumer Lag Monitoring
-
-- Expose consumer lag metrics via broker-native tooling (e.g., Kafka Consumer Groups).
-- Set alert thresholds: warning at 10,000 messages, critical at 100,000 messages lag.
-- Track lag trends weekly; investigate persistent lag growth.
-
-## Dead-Letter Queue (DLQ) Handling — ED-R03
-
-- Route unprocessable messages to DLQ after configurable retry exhaustion (default: 3 attempts).
-- Monitor DLQ depth daily; messages older than 72 hours require manual triage.
-- Implement DLQ replay tooling with idempotency guards before reprocessing.
-
-## Event Flow Observability — ED-R08
-
-- Instrument producers and consumers with distributed tracing (OpenTelemetry).
-- Capture event metadata: topic, partition, offset, timestamp, producer ID.
-- Maintain event flow dashboards showing produce/consume rates, error rates, and end-to-end latency.
-
-## Partition Management — ED-R04
-
-- Design partition keys to ensure ordering guarantees where required.
-- Avoid hot partitions by distributing keys across high-cardinality domains.
-- Monitor per-partition throughput; rebalance when variance exceeds 3x across partitions.
-
-## Composable Applicability
-
-| Composable | Guidance |
-|---|---|
-| Modular Monolith | Embedded broker; partition management is intra-process. |
-| Distributed Modules | Shared broker cluster; cross-module consumer lag monitoring required. |
-| Microservices | Full broker infrastructure; per-service consumer group isolation. |
-| Serverless | Managed broker services; partition scaling handled by provider. |
-| Edge Computing | Local broker instances with periodic cloud sync. |
-
-## ADR References
-
-- **ADR-0015**: Event broker infrastructure and partitioning strategy.
-- **ADR-0079**: Event observability and monitoring standards.
-
----
-
-[Back to Event-Driven Profile](./README.md)

package/rulesets/topologies/event-driven/parity-fixtures/compliant.json

@@ -1,18 +0,0 @@
-{
-  "input": {
-    "satellite": {
-      "eventDriven": {
-        "hasStrictAsyncApi": true,
-        "hasOutbox": true,
-        "hasDlq": true,
-        "hasOrderingGuarantee": true,
-        "hasIdempotencyKey": true,
-        "hasBackwardCompatibleSchema": true,
-        "hasRetentionPolicy": true,
-        "hasEventCorrelation": true,
-        "hasConsumerGroupRegistry": true
-      }
-    }
-  },
-  "expectedNative": []
-}

package/rulesets/topologies/event-driven/parity-fixtures/violation.json

@@ -1,21 +0,0 @@
-{
-  "input": {
-    "satellite": {
-      "eventDriven": {
-        "hasStrictAsyncApi": false,
-        "hasOutbox": true,
-        "hasDlq": true,
-        "hasOrderingGuarantee": false,
-        "hasIdempotencyKey": true,
-        "hasBackwardCompatibleSchema": true,
-        "hasRetentionPolicy": true,
-        "hasEventCorrelation": true,
-        "hasConsumerGroupRegistry": true
-      }
-    }
-  },
-  "expectedNative": [
-    { "ruleId": "ED-R01", "severity": "error", "file": null },
-    { "ruleId": "ED-R04", "severity": "error", "file": null }
-  ]
-}

package/rulesets/topologies/event-driven/patterns.es.md

@@ -1,68 +0,0 @@
-# Guía de Patrones Orientada a Eventos
-
-> **Navegación Bilingüe:** [English](./patterns.md) | [Español](./patterns.es.md)
-
-**Propietario:** Junta de Arquitectura
-**Topología:** Orientada a Eventos
-
-## Propósito
-
-Documentar patrones fundamentales orientados a eventos: almacenamiento de eventos, CQRS, saga, outbox transaccional, captura de cambios de datos (CDC) y tradeoffs entre coreografía y orquestación.
-
-## Almacenamiento de Eventos (Event Sourcing)
-
-- Persistir estado como una secuencia inmutable de eventos en lugar de instantáneas del estado actual.
-- Reconstruir estado reproduciendo eventos desde el inicio del flujo.
-- Usar snapshots periódicamente para acotar el tiempo de reproducción (por ejemplo, cada 1,000 eventos).
-
-## CQRS (Segregación de Responsabilidades de Comando y Consulta)
-
-- Separar modelo de escritura (comandos) del modelo de lectura (consultas) para escalado independiente.
-- Sincronizar modelo de lectura mediante eventos publicados desde el lado de escritura.
-- Aceptar consistencia eventual entre modelos de escritura y lectura; diseñar UIs en consecuencia.
-
-## Patrón Saga
-
-- Coordinar procesos de negocio de múltiples pasos como una secuencia de transacciones locales.
-- Implementar transacciones compensatorias para reversión cuando un paso falla.
-- Preferir coreografía (orientada a eventos) para sagas simples; usar orquestación (coordinador central) para flujos de trabajo complejos y de larga ejecución.
-
-## Outbox Transaccional — ED-R02
-
-- Asegurar publicación confiable de eventos escribiendo eventos en un outbox dentro de la misma transacción de BD que la escritura de negocio.
-- Usar CDC (Debezium) o un editor de sondeo para transmitir eventos del outbox al broker.
-- Deduplicar del lado del consumidor; el outbox puede publicar duplicados durante failover.
-
-## Captura de Cambios de Datos (CDC)
-
-- Transmitir cambios de base de datos como eventos sin modificar el código de la aplicación.
-- Usar Debezium o conectores equivalentes para PostgreSQL, MySQL o SQL Server.
-- Monitorear retraso del conector; alertar cuando el retraso exceda 5 minutos.
-
-## Coreografía vs. Orquestación — ED-R04
-
-| Aspecto | Coreografía | Orquestación |
-|---|---|---|
-| Acoplamiento | Loose; los servicios reaccionan a eventos | Más fuerte; el coordinador invoca servicios |
-| Visibilidad | Distribuida; más difícil de rastrear | Centralizada; más fácil de monitorear |
-| Manejo de errores | Eventos compensatorios por servicio | Reintento y compensación centralizados |
-| Caso de uso | Flujos simples de pocos pasos | Complejos, multi-servicio, larga ejecución |
-
-## Aplicabilidad Componible
-
-| Componible | Orientación |
-|---|---|
-| Monolito Modular | Almacenamiento de eventos y CQRS dentro de límites de módulos; outbox es intra-BD. |
-| Módulos Distribuidos | Saga entre módulos; coreografía preferida para acoplamiento loose. |
-| Microservicios | Saga completo con orquestación o coreografía; CDC para sincronización de datos. |
-| Serverless | Almacenamiento de eventos con flujos gestionados; CDC vía conectores gestionados. |
-| Computación Edge | Almacenamiento de eventos local con sincronización periódica a la nube. |
-
-## Referencias ADR
-
-- **ADR-0015**: Criterios de adopción de almacenamiento de eventos y CQRS.
-- **ADR-0079**: Marco de decisión de orquestación vs. coreografía en saga.
-
----
-
-[Volver al Perfil Orientado a Eventos](./README.es.md)

package/rulesets/topologies/event-driven/patterns.md

@@ -1,68 +0,0 @@
-# Event-Driven — Patterns Guide
-
-> **Bilingual Navigation:** [English](./patterns.md) | [Español](./patterns.es.md)
-
-**Owner:** Architecture Board
-**Topology:** Event-Driven
-
-## Purpose
-
-Document core event-driven patterns: event sourcing, CQRS, saga, transactional outbox, change data capture (CDC), and choreography vs. orchestration tradeoffs.
-
-## Event Sourcing
-
-- Persist state as an immutable sequence of events rather than current-state snapshots.
-- Rebuild state by replaying events from the beginning of the stream.
-- Use snapshots periodically to bound replay time (e.g., every 1,000 events).
-
-## CQRS (Command Query Responsibility Segregation)
-
-- Separate write model (commands) from read model (queries) for independent scaling.
-- Synchronize read model via events published from the write side.
-- Accept eventual consistency between write and read models; design UIs accordingly.
-
-## Saga Pattern
-
-- Coordinate multi-step business processes as a sequence of local transactions.
-- Implement compensating transactions for rollback when a step fails.
-- Prefer choreography (event-driven) for simple sagas; use orchestration (central coordinator) for complex, long-running workflows.
-
-## Transactional Outbox — ED-R02
-
-- Ensure reliable event publication by writing events to an outbox within the same DB transaction as the business write.
-- Use CDC (Debezium) or a polling publisher to relay outbox events to the broker.
-- Deduplicate at the consumer side; the outbox may publish duplicates during failover.
-
-## Change Data Capture (CDC)
-
-- Stream database changes as events without modifying application code.
-- Use Debezium or equivalent connectors for PostgreSQL, MySQL, or SQL Server.
-- Monitor connector lag; alert when lag exceeds 5 minutes.
-
-## Choreography vs. Orchestration — ED-R04
-
-| Aspect | Choreography | Orchestration |
-|---|---|---|
-| Coupling | Loose; services react to events | Tighter; coordinator invokes services |
-| Visibility | Distributed; harder to trace | Centralized; easier to monitor |
-| Error handling | Compensating events per service | Centralized retry and compensation |
-| Use case | Simple, few-step workflows | Complex, multi-service, long-running |
-
-## Composable Applicability
-
-| Composable | Guidance |
-|---|---|
-| Modular Monolith | Event sourcing and CQRS within module boundaries; outbox is intra-DB. |
-| Distributed Modules | Saga across modules; choreography preferred for loose coupling. |
-| Microservices | Full saga with orchestration or choreography; CDC for data synchronization. |
-| Serverless | Event sourcing with managed streams; CDC via managed connectors. |
-| Edge Computing | Local event sourcing with periodic cloud synchronization. |
-
-## ADR References
-
-- **ADR-0015**: Event sourcing and CQRS adoption criteria.
-- **ADR-0079**: Saga orchestration vs. choreography decision framework.
-
----
-
-[Back to Event-Driven Profile](./README.md)

package/rulesets/topologies/event-driven/resilience.es.md

@@ -1,65 +0,0 @@
-# Guía de Resiliencia Orientada a Eventos
-
-> **Navegación Bilingüe:** [English](./resilience.md) | [Español](./resilience.es.md)
-
-**Propietario:** Junta de Arquitectura
-**Topología:** Orientada a Eventos
-
-## Propósito
-
-Definir patrones de resiliencia para arquitecturas orientadas a eventos: consumidores idempotentes, semántica de exactamente una vez, manejo de píldoras venenosas, retroceso de reintentos, rebalanceo de consumidores y outbox transaccional.
-
-## Consumidores Idempotentes — ED-R05
-
-- Cada consumidor DEBE procesar eventos de forma idempotente; se asume entrega duplicada.
-- Usar claves de deduplicación compuestas por `(event-id, consumer-group)` almacenadas en una caché duradera.
-- Establecer la ventana de deduplicación en al menos 2x el período máximo de retención del broker.
-
-## Semántica de Exactamente Una Vez
-
-- Preferir productores idempotentes con IDs de productor sobre garantías de exactamente una vez a nivel de broker.
-- Para flujos de trabajo críticos, usar productores transaccionales que escriban atómicamente en múltiples temas.
-- Documentar el nivel de garantía semántica (al menos una vez, efectivamente una vez) por consumidor.
-
-## Manejo de Píldoras Venenosas — ED-R03
-
-- Detectar píldoras venenosas rastreando conteos de reintentos por mensaje en el estado del consumidor.
-- Después del agotamiento configurable de reintentos (predeterminado: 3), enrutar el mensaje a DLQ con contexto completo.
-- Alertar cuando la tasa de píldoras venenosas exceda el 0.1% del volumen total de mensajes.
-
-## Retroceso de Reintentos
-
-- Implementar retroceso exponencial con jitter: `base * 2^attempto + random(0, base)`.
-- Establecer un máximo de retraso de reintento de 5 minutos; escalar a DLQ después de alcanzar el máximo.
-- Usar colas de reintento separadas para categorías de falla transitoria vs. permanente.
-
-## Rebalanceo de Consumidores
-
-- Diseñar consumidores para manejar eventos de rebalanceo con gracia; pausar procesamiento durante rebalanceo.
-- Usar asignación de partición cooperativa y pegajosa para minimizar movimiento de particiones.
-- Monitorear frecuencia de rebalanceo; investigar si los rebalanceos exceden 1 por hora por grupo de consumidores.
-
-## Outbox Transaccional — ED-R02
-
-- Escribir eventos de dominio en una tabla de outbox dentro de la misma transacción que los cambios de estado del negocio.
-- Publicar eventos de outbox mediante CDC o editor de sondeo al broker.
-- Garantizar que los registros de outbox se publiquen eventualmente; monitorear la profundidad del outbox.
-
-## Aplicabilidad Componible
-
-| Componible | Orientación |
-|---|---|
-| Monolito Modular | El outbox es intra-base de datos; idempotencia vía caché compartida. |
-| Módulos Distribuidos | El outbox entre módulos requiere diseño cuidadoso de límites de transacción. |
-| Microservicios | Outbox por servicio; aislamiento de consumidores por límite de servicio. |
-| Serverless | Deduplicación gestionada; outbox mediante disparadores de base de datos. |
-| Computación Edge | Outbox local con sincronización eventual al broker en la nube. |
-
-## Referencias ADR
-
-- **ADR-0015**: Estándares de resiliencia de consumidores y políticas de reintento.
-- **ADR-0079**: Patrón de implementación de outbox transaccional.
-
----
-
-[Volver al Perfil Orientado a Eventos](./README.es.md)