@evolith/core-domain 1.0.1 → 1.0.2

package/rulesets/topologies/event-driven/cli/cli-flows.md

@@ -1,53 +0,0 @@
-# Event-Driven — CLI Flows
-
-> **Bilingual Navigation:** [Versión en Español](./cli-flows.es.md)
-
-**Validators declarados:** `validate-architecture`, `validate-topology`
-
-The following CLI commands are available for the Event-Driven topology.
-
-## Validate
-
-```bash
-evolith validate --topology event-driven
-evolith validate --topology event-driven --arch-level F2
-evolith validate --topology event-driven --format json
-```
-
-Validates an Event-Driven configuration against the topology's native rules (`event-driven.rules.json`) and OPA Rego policies (`event-driven.rego`), checking message ordering, idempotency, eventual consistency, and event channel governance.
-
-## Inspect
-
-```bash
-evolith topology inspect event-driven
-evolith topology inspect event-driven --include-channels
-```
-
-Returns the parsed Event-Driven topology manifest, event channel and subscription metadata, and corpus artifact references.
-
-## Drift
-
-```bash
-evolith drift detect --topology event-driven
-evolith drift detect --topology event-driven --format json
-```
-
-Detects configuration drift between the Event-Driven topology's declared ruleset and the current workspace state.
-
-## Scaffold
-
-```bash
-evolith architecture scaffold --topology event-driven
-evolith architecture scaffold --topology event-driven --dry-run
-```
-
-Scaffolds an Event-Driven topology workspace with the canonical corpus structure, manifest, config schema, and OPA policies.
-
-## Gate Evaluation
-
-```bash
-evolith gate evaluate --topology event-driven
-evolith gate evaluate --topology event-driven --phase F1
-```
-
-Evaluates Event-Driven phase gates, validating message contract conformance and channel ownership.

package/rulesets/topologies/event-driven/event-driven.rego

@@ -1,11 +0,0 @@
-package evolith.topologies.eventdriven
-
-violations[{"id":"ED-R01","blocking":true,"message":"event-driven.config.json must declare strictAsyncApi=true (ED-R01)."}] { not input.satellite.eventDriven.hasStrictAsyncApi }
-violations[{"id":"ED-R02","blocking":true,"message":"event-driven.config.json must declare transactionalOutbox=true (ED-R02)."}] { not input.satellite.eventDriven.hasOutbox }
-violations[{"id":"ED-R03","blocking":true,"message":"event-driven.config.json must declare deadLetterQueue=true (ED-R03)."}] { not input.satellite.eventDriven.hasDlq }
-violations[{"id":"ED-R04","blocking":true,"message":"event-driven.config.json must declare hasOrderingGuarantee=true (ED-R04)."}] { not input.satellite.eventDriven.hasOrderingGuarantee }
-violations[{"id":"ED-R05","blocking":true,"message":"All event consumers must implement idempotency; event-driven.config.json must declare hasIdempotencyKey=true (ED-R05)."}] { not input.satellite.eventDriven.hasIdempotencyKey }
-violations[{"id":"ED-R06","blocking":true,"message":"Event schemas must evolve in a backward-compatible manner; event-driven.config.json must declare hasBackwardCompatibleSchema=true (ED-R06)."}] { not input.satellite.eventDriven.hasBackwardCompatibleSchema }
-violations[{"id":"ED-R07","blocking":false,"message":"event-driven.config.json must declare hasRetentionPolicy=true with an explicit retention window per topic (ED-R07)."}] { not input.satellite.eventDriven.hasRetentionPolicy }
-violations[{"id":"ED-R08","blocking":false,"message":"All published events must carry CorrelationId and TraceId headers; event-driven.config.json must declare hasEventCorrelation=true (ED-R08)."}] { not input.satellite.eventDriven.hasEventCorrelation }
-violations[{"id":"ED-R09","blocking":false,"message":"All consumers should register a named consumer group; event-driven.config.json should declare hasConsumerGroupRegistry=true (ED-R09)."}] { not input.satellite.eventDriven.hasConsumerGroupRegistry }

package/rulesets/topologies/event-driven/event-driven.rules.json

@@ -1,100 +0,0 @@
-{
-  "$schema": "../../../../../rulesets/schema/ruleset-standard.schema.json",
-  "$id": "https://evolith.dev/rulesets/topologies/event-driven.rules.json",
-  "title": "Event-Driven Topology Rules",
-  "description": "Architectural rules for the event-driven integration topology.",
-  "version": "1.1.0",
-  "effectiveDate": "2026-06-22",
-  "rules": [
-    {
-      "id": "ED-R01",
-      "severity": "MUST",
-      "category": "event-driven-config",
-      "title": "Strict AsyncAPI Contract",
-      "description": "An Event-Driven satellite MUST provide event-driven.config.json and declare strictAsyncApi=true.",
-      "rationale": "AsyncAPI contracts provide machine-readable event schemas that enable consumer code generation, documentation, and contract testing. Without this declaration, event shape regressions go undetected across producer/consumer boundaries.",
-      "validationQuery": "Verify event-driven.config.json exists and strictAsyncApi is set to true. No event publication allowed without a registered AsyncAPI document.",
-      "blocking": true
-    },
-    {
-      "id": "ED-R02",
-      "severity": "MUST",
-      "category": "event-driven-outbox",
-      "title": "Transactional Outbox",
-      "description": "event-driven.config.json MUST declare transactionalOutbox=true.",
-      "rationale": "Direct broker publication inside a database transaction risks dual-write failures where the DB commits but the message is lost. The Transactional Outbox pattern guarantees at-least-once delivery by staging messages in the same transaction as domain writes.",
-      "validationQuery": "Verify event-driven.config.json declares transactionalOutbox=true. Confirm outbox relay job or CDC mechanism is present in the infrastructure layer.",
-      "blocking": true
-    },
-    {
-      "id": "ED-R03",
-      "severity": "MUST",
-      "category": "event-driven-dlq",
-      "title": "Dead Letter Queue",
-      "description": "event-driven.config.json MUST declare deadLetterQueue=true.",
-      "rationale": "Without a DLQ, poison messages cause unbounded consumer retry loops that starve healthy message processing and degrade system availability. A DLQ enables forensic analysis of failed deliveries and controlled replay.",
-      "validationQuery": "Verify event-driven.config.json declares deadLetterQueue=true. Confirm DLQ topic or queue exists in broker configuration and consumer error handler routes to it.",
-      "blocking": true
-    },
-    {
-      "id": "ED-R04",
-      "severity": "MUST",
-      "category": "event-ordering",
-      "title": "Event Ordering Guarantee",
-      "description": "An Event-Driven satellite MUST declare its ordering guarantee (e.g., partition-key ordering or total ordering) in event-driven.config.json via hasOrderingGuarantee=true.",
-      "rationale": "Undeclared ordering assumptions lead to race conditions in downstream consumers that process state transitions out of sequence. Explicit ordering guarantees force architectural decisions (e.g., partition-key selection) to be made deliberately rather than discovered in production.",
-      "validationQuery": "Verify event-driven.config.json declares hasOrderingGuarantee=true and that a partitioning strategy (e.g., aggregateId as partition key) is documented in the event schema.",
-      "blocking": true
-    },
-    {
-      "id": "ED-R05",
-      "severity": "MUST",
-      "category": "idempotency",
-      "title": "Idempotent Consumer Contract",
-      "description": "All event consumers MUST implement idempotency using a deduplicated message key (hasIdempotencyKey=true in event-driven.config.json).",
-      "rationale": "At-least-once delivery guarantees (required by ED-R02) mean duplicate messages are possible. Without idempotent consumers, duplicate processing causes data corruption, double billing, or ghost records. Idempotency keys (e.g., eventId) enable safe re-delivery.",
-      "validationQuery": "Verify event-driven.config.json declares hasIdempotencyKey=true. AST scan consumer handlers for idempotency guard using a deduplication store (Redis, DB unique key, etc.).",
-      "blocking": true
-    },
-    {
-      "id": "ED-R06",
-      "severity": "MUST",
-      "category": "schema-evolution",
-      "title": "Backward-Compatible Schema Evolution",
-      "description": "All event schemas MUST be evolved in a backward-compatible manner (hasBackwardCompatibleSchema=true). Breaking changes require a new event type version.",
-      "rationale": "Consumers evolve independently of producers. A breaking schema change — removing a field, changing a type — silently breaks consumers that cannot be updated in lockstep. Backward compatibility (Avro/JSONSchema additionalProperties, optional fields) allows independent rollout.",
-      "validationQuery": "Verify event-driven.config.json declares hasBackwardCompatibleSchema=true. Validate that event schema changes pass backward-compatibility checks in CI (e.g., Confluent Schema Registry compatibility check or JSON Schema diff tool).",
-      "blocking": true
-    },
-    {
-      "id": "ED-R07",
-      "severity": "MUST",
-      "category": "retention",
-      "title": "Retention Policy Declaration",
-      "description": "event-driven.config.json MUST declare hasRetentionPolicy=true with an explicit retention window per topic.",
-      "rationale": "Unmanaged event retention leads to unbounded storage growth. Explicit retention windows enable capacity planning, regulatory compliance (GDPR deletion within SLA), and replay boundary definition for event sourcing scenarios.",
-      "validationQuery": "Verify event-driven.config.json declares hasRetentionPolicy=true. Confirm each topic has an explicit retention duration documented in broker configuration or Infrastructure-as-Code.",
-      "blocking": false
-    },
-    {
-      "id": "ED-R08",
-      "severity": "MUST",
-      "category": "observability",
-      "title": "Event Observability (Correlation and Trace Propagation)",
-      "description": "All published events MUST carry a CorrelationId and TraceId header (hasEventCorrelation=true), propagated from the originating HTTP/CLI/MCP request context.",
-      "rationale": "Without trace propagation, distributed event flows are invisible in observability tooling. Engineers cannot reconstruct the causal chain from an HTTP request through async processing to its eventual side effects, making incident response and latency debugging extremely difficult.",
-      "validationQuery": "Verify event-driven.config.json declares hasEventCorrelation=true. AST scan event publisher adapters for CorrelationId and TraceId header injection. Verify consumer handlers extract and re-propagate trace context.",
-      "blocking": false
-    },
-    {
-      "id": "ED-R09",
-      "severity": "SHOULD",
-      "category": "consumer-groups",
-      "title": "Explicit Consumer Group Registration",
-      "description": "All event consumers SHOULD register in a named consumer group declared in event-driven.config.json (hasConsumerGroupRegistry=true) to enable per-consumer offset tracking and independent replay.",
-      "rationale": "Anonymous consumer groups prevent selective replay, blue/green consumer deployments, and lag monitoring per service. Explicit registration enables fine-grained operational control over consumer progress and rollback scenarios.",
-      "validationQuery": "Verify event-driven.config.json declares hasConsumerGroupRegistry=true. Confirm all consumer instances are configured with an explicit, deterministic consumer group name (not auto-generated).",
-      "blocking": false
-    }
-  ]
-}

package/rulesets/topologies/event-driven/event-driven.test.rego

@@ -1,107 +0,0 @@
-package evolith.topologies.eventdriven_test
-
-import data.evolith.topologies.eventdriven
-
-# --- Baseline rules (ED-R01–R03) ---
-
-test_compliant_event_driven_has_no_violations {
-  violations := eventdriven.violations with input as {"satellite": {"eventDriven": {
-    "hasStrictAsyncApi": true, "hasOutbox": true, "hasDlq": true,
-    "hasOrderingGuarantee": true, "hasIdempotencyKey": true,
-    "hasBackwardCompatibleSchema": true, "hasRetentionPolicy": true,
-    "hasEventCorrelation": true, "hasConsumerGroupRegistry": true
-  }}}
-  count(violations) == 0
-}
-
-test_missing_asyncapi_is_rejected {
-  violations := eventdriven.violations with input as {"satellite": {"eventDriven": {
-    "hasStrictAsyncApi": false, "hasOutbox": true, "hasDlq": true,
-    "hasOrderingGuarantee": true, "hasIdempotencyKey": true,
-    "hasBackwardCompatibleSchema": true, "hasRetentionPolicy": true,
-    "hasEventCorrelation": true, "hasConsumerGroupRegistry": true
-  }}}
-  violations[_].id == "ED-R01"
-}
-
-test_missing_outbox_is_rejected {
-  violations := eventdriven.violations with input as {"satellite": {"eventDriven": {
-    "hasStrictAsyncApi": true, "hasOutbox": false, "hasDlq": true,
-    "hasOrderingGuarantee": true, "hasIdempotencyKey": true,
-    "hasBackwardCompatibleSchema": true, "hasRetentionPolicy": true,
-    "hasEventCorrelation": true, "hasConsumerGroupRegistry": true
-  }}}
-  violations[_].id == "ED-R02"
-}
-
-test_missing_dlq_is_rejected {
-  violations := eventdriven.violations with input as {"satellite": {"eventDriven": {
-    "hasStrictAsyncApi": true, "hasOutbox": true, "hasDlq": false,
-    "hasOrderingGuarantee": true, "hasIdempotencyKey": true,
-    "hasBackwardCompatibleSchema": true, "hasRetentionPolicy": true,
-    "hasEventCorrelation": true, "hasConsumerGroupRegistry": true
-  }}}
-  violations[_].id == "ED-R03"
-}
-
-# --- New rules (ED-R04–R09) ---
-
-test_missing_ordering_guarantee_is_rejected {
-  violations := eventdriven.violations with input as {"satellite": {"eventDriven": {
-    "hasStrictAsyncApi": true, "hasOutbox": true, "hasDlq": true,
-    "hasOrderingGuarantee": false, "hasIdempotencyKey": true,
-    "hasBackwardCompatibleSchema": true, "hasRetentionPolicy": true,
-    "hasEventCorrelation": true, "hasConsumerGroupRegistry": true
-  }}}
-  violations[_].id == "ED-R04"
-}
-
-test_missing_idempotency_key_is_rejected {
-  violations := eventdriven.violations with input as {"satellite": {"eventDriven": {
-    "hasStrictAsyncApi": true, "hasOutbox": true, "hasDlq": true,
-    "hasOrderingGuarantee": true, "hasIdempotencyKey": false,
-    "hasBackwardCompatibleSchema": true, "hasRetentionPolicy": true,
-    "hasEventCorrelation": true, "hasConsumerGroupRegistry": true
-  }}}
-  violations[_].id == "ED-R05"
-}
-
-test_missing_backward_compatible_schema_is_rejected {
-  violations := eventdriven.violations with input as {"satellite": {"eventDriven": {
-    "hasStrictAsyncApi": true, "hasOutbox": true, "hasDlq": true,
-    "hasOrderingGuarantee": true, "hasIdempotencyKey": true,
-    "hasBackwardCompatibleSchema": false, "hasRetentionPolicy": true,
-    "hasEventCorrelation": true, "hasConsumerGroupRegistry": true
-  }}}
-  violations[_].id == "ED-R06"
-}
-
-test_missing_retention_policy_is_flagged {
-  violations := eventdriven.violations with input as {"satellite": {"eventDriven": {
-    "hasStrictAsyncApi": true, "hasOutbox": true, "hasDlq": true,
-    "hasOrderingGuarantee": true, "hasIdempotencyKey": true,
-    "hasBackwardCompatibleSchema": true, "hasRetentionPolicy": false,
-    "hasEventCorrelation": true, "hasConsumerGroupRegistry": true
-  }}}
-  violations[_].id == "ED-R07"
-}
-
-test_missing_event_correlation_is_flagged {
-  violations := eventdriven.violations with input as {"satellite": {"eventDriven": {
-    "hasStrictAsyncApi": true, "hasOutbox": true, "hasDlq": true,
-    "hasOrderingGuarantee": true, "hasIdempotencyKey": true,
-    "hasBackwardCompatibleSchema": true, "hasRetentionPolicy": true,
-    "hasEventCorrelation": false, "hasConsumerGroupRegistry": true
-  }}}
-  violations[_].id == "ED-R08"
-}
-
-test_missing_consumer_group_registry_is_flagged {
-  violations := eventdriven.violations with input as {"satellite": {"eventDriven": {
-    "hasStrictAsyncApi": true, "hasOutbox": true, "hasDlq": true,
-    "hasOrderingGuarantee": true, "hasIdempotencyKey": true,
-    "hasBackwardCompatibleSchema": true, "hasRetentionPolicy": true,
-    "hasEventCorrelation": true, "hasConsumerGroupRegistry": false
-  }}}
-  violations[_].id == "ED-R09"
-}

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

@@ -1,69 +0,0 @@
-# Guía de Evidencia Orientada a Eventos
-
-> **Navegación Bilingüe:** [English](./evidence.md) | [Español](./evidence.es.md)
-
-**Propietario:** Junta de Arquitectura
-**Topología:** Orientada a Eventos
-
-## Propósito
-
-Definir comandos de validación, métricas y verificaciones de cumplimiento para evidenciar la salud de arquitecturas orientadas a eventos: throughput, retraso de consumidores, latencia de procesamiento, profundidad de DLQ y cumplimiento de contratos.
-
-## Comandos de Validación
-
-| Verificación | Comando |
-|---|---|
-| Salud del broker | `kafka-broker-api-versions.sh --bootstrap-server <host>:9092` |
-| Estado del grupo de consumidores | `kafka-consumer-groups.sh --bootstrap-server <host>:9092 --group <group> --describe` |
-| Listado de temas | `kafka-topics.sh --bootstrap-server <host>:9092 --list` |
-| Verificación de registro de esquemas | `curl -s <schema-registry>/subjects` |
-| Profundidad de DLQ | Consultar conteo de mensajes del tema DLQ vía API de métricas del broker |
-
-## Throughput de Eventos — ED-R08
-
-- Medir mensajes producidos y consumidos por segundo por tema.
-- Mantener throughput sostenido dentro del 70% de la capacidad pico del broker.
-- Alertar en caídas de throughput que excedan el 20% del promedio móvil de 7 días.
-
-## Retraso de Consumidores — ED-R08
-
-- Reportar retraso actual por grupo de consumidores por partición.
-- Agregar retraso entre particiones para evaluación de salud a nivel de grupo.
-- Rastrear tendencia del retraso: estable, creciente o decreciente en ventanas de 24 horas.
-
-## Latencia de Procesamiento — ED-R08
-
-- Medir latencia de extremo a extremo: marca de tiempo de producción del evento a marca de tiempo de consumo del evento.
-- Mantener latencia P99 bajo 5 segundos para rutas en tiempo real; bajo 60 segundos para rutas por lotes.
-- Alertar en picos de latencia que excedan 3x la línea base.
-
-## Profundidad de DLQ — ED-R03
-
-- Monitorear conteo de mensajes DLQ por tema por grupo de consumidores.
-- Alertar cuando la profundidad de DLQ exceda 100 mensajes o crezca >10% por hora.
-- Reportar antigüedad de DLQ: marca de tiempo del mensaje más antiguo por tema DLQ.
-
-## Cumplimiento de Contratos — ED-R01, ED-R06
-
-- Validar esquemas de productores contra la especificación AsyncAPI registrada.
-- Ejecutar verificaciones de compatibilidad de esquemas: `kafka-schema-registry.sh check-compatibility`.
-- Reportar deriva de esquemas: eventos publicados con esquemas no registrados o deprecados.
-
-## Aplicabilidad Componible
-
-| Componible | Orientación |
-|---|---|
-| Monolito Modular | Métricas recolectadas a nivel de proceso; validación ligera. |
-| Módulos Distribuidos | Agregación de métricas entre módulos; paneles centralizados. |
-| Microservicios | Métricas por servicio con plataforma de observabilidad centralizada. |
-| Serverless | Métricas nativas del proveedor; exportar a monitoreo centralizado. |
-| Computación Edge | Recolección local de métricas con carga periódica a la nube. |
-
-## Referencias ADR
-
-- **ADR-0015**: Estándares de monitoreo de throughput y retraso de eventos.
-- **ADR-0079**: Requisitos de recolección de evidencia de observabilidad.
-
----
-
-[Volver al Perfil Orientado a Eventos](./README.es.md)

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

@@ -1,69 +0,0 @@
-# Event-Driven — Evidence Guide
-
-> **Bilingual Navigation:** [English](./evidence.md) | [Español](./evidence.es.md)
-
-**Owner:** Architecture Board
-**Topology:** Event-Driven
-
-## Purpose
-
-Define validation commands, metrics, and compliance checks for evidencing event-driven architecture health: throughput, consumer lag, processing latency, DLQ depth, and contract compliance.
-
-## Validation Commands
-
-| Check | Command |
-|---|---|
-| Broker health | `kafka-broker-api-versions.sh --bootstrap-server <host>:9092` |
-| Consumer group status | `kafka-consumer-groups.sh --bootstrap-server <host>:9092 --group <group> --describe` |
-| Topic listing | `kafka-topics.sh --bootstrap-server <host>:9092 --list` |
-| Schema registry check | `curl -s <schema-registry>/subjects` |
-| DLQ depth | Query DLQ topic message count via broker metrics API |
-
-## Event Throughput — ED-R08
-
-- Measure messages produced and consumed per second per topic.
-- Target sustained throughput within 70% of broker peak capacity.
-- Alert on throughput drops exceeding 20% from the 7-day rolling average.
-
-## Consumer Lag — ED-R08
-
-- Report current lag per consumer group per partition.
-- Aggregate lag across partitions for group-level health assessment.
-- Track lag trend: stable, growing, or shrinking over 24-hour windows.
-
-## Processing Latency — ED-R08
-
-- Measure end-to-end latency: event produced timestamp to event consumed timestamp.
-- Target P99 latency under 5 seconds for real-time paths; under 60 seconds for batch paths.
-- Alert on latency spikes exceeding 3x the baseline.
-
-## DLQ Depth — ED-R03
-
-- Monitor DLQ message count per topic per consumer group.
-- Alert when DLQ depth exceeds 100 messages or grows by >10% per hour.
-- Report DLQ age: oldest message timestamp per DLQ topic.
-
-## Contract Compliance — ED-R01, ED-R06
-
-- Validate producer schemas against the registered AsyncAPI specification.
-- Run schema compatibility checks: `kafka-schema-registry.sh check-compatibility`.
-- Report schema drift: events published with unregistered or deprecated schemas.
-
-## Composable Applicability
-
-| Composable | Guidance |
-|---|---|
-| Modular Monolith | Metrics collected at process level; lightweight validation. |
-| Distributed Modules | Cross-module metric aggregation; centralized dashboards. |
-| Microservices | Per-service metrics with centralized observability platform. |
-| Serverless | Provider-native metrics; export to centralized monitoring. |
-| Edge Computing | Local metric collection with periodic cloud upload. |
-
-## ADR References
-
-- **ADR-0015**: Event throughput and lag monitoring standards.
-- **ADR-0079**: Observability evidence collection requirements.
-
----
-
-[Back to Event-Driven Profile](./README.md)

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

@@ -1,59 +0,0 @@
-# Guía de Evolución Orientada a Eventos
-
-> **Navegación Bilingüe:** [English](./evolution.md) | [Español](./evolution.es.md)
-
-**Propietario:** Junta de Arquitectura
-**Topología:** Orientada a Eventos
-
-## Propósito
-
-Guiar la evolución de sistemas orientados a eventos: migración de patrones síncronos a asincrónicos, evolución de esquemas, estrategias de versionado y gobernanza del catálogo de eventos.
-
-## Migración de Síncrono a Asincrónico
-
-- Identificar cadenas de llamadas síncronas que bloquean en dependencias externas; candidatas para extracción de eventos.
-- Comenzar con rutas no críticas (notificaciones, analíticas) antes de migrar flujos transaccionales.
-- Ejecutar rutas síncronas y asincrónicas en paralelo durante la migración; deprecar la síncrona después de validación.
-
-## Evolución de Esquemas — ED-R06
-
-- Preferir cambios aditivos: agregar campos opcionales con valores predeterminados sobre eliminar o renombrar campos.
-- Mantener compatibilidad hacia atrás por al menos 2 ciclos de lanzamiento mayores.
-- Usar modos de compatibilidad del registro de esquemas: BACKWARD (consumidores toleran nuevos campos), FORWARD (productores toleran consumidores antiguos), FULL (ambos).
-
-## Estrategia de Versionado
-
-- Incrustar versión en el sobre del evento: `event-version: "1.2.0"`.
-- Usar versionado semántico para cambios de esquema: mayor (ruptura), menor (aditivo), parche (correcciones).
-- Mantener una tabla de mapeo de versiones para rutas de migración entre versiones mayores.
-
-## Gobernanza del Catálogo de Eventos — ED-R07
-
-- Registrar cada tipo de evento en un catálogo centralizado con metadatos de propiedad, dominio y retención.
-- Requerir entrada en el catálogo antes de publicar un nuevo tipo de evento en cualquier entorno.
-- Revisar el catálogo trimestralmente; archivar eventos no utilizados después de confirmación de partes interesadas.
-
-## Proceso de Depreciación
-
-- Marcar eventos deprecados con `deprecated: true` en el catálogo y registro de esquemas.
-- Mantener eventos deprecados por un mínimo de 6 meses o 2 ciclos de lanzamiento, lo que sea mayor.
-- Monitorear uso de eventos deprecados por consumidores; notificar a equipos propietarios cuando los consumidores permanezcan.
-
-## Aplicabilidad Componible
-
-| Componible | Orientación |
-|---|---|
-| Monolito Modular | Evolución de esquemas dentro del módulo; catálogo es intra-proceso. |
-| Módulos Distribuidos | Coordinación de esquemas entre módulos; catálogo compartido requerido. |
-| Microservicios | Catálogo de eventos por dominio; registro de esquemas como infraestructura compartida. |
-| Serverless | Registro de esquemas gestionado; versionado enforced por la plataforma. |
-| Computación Edge | Caché local de esquemas con sincronización periódica desde catálogo central. |
-
-## Referencias ADR
-
-- **ADR-0015**: Política de evolución de esquemas y versionado.
-- **ADR-0079**: Gobernanza del catálogo de eventos y gestión del ciclo de vida.
-
----
-
-[Volver al Perfil Orientado a Eventos](./README.es.md)

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

@@ -1,59 +0,0 @@
-# Event-Driven — Evolution Guide
-
-> **Bilingual Navigation:** [English](./evolution.md) | [Español](./evolution.es.md)
-
-**Owner:** Architecture Board
-**Topology:** Event-Driven
-
-## Purpose
-
-Guide the evolution of event-driven systems: migrating from synchronous to asynchronous patterns, schema evolution, versioning strategies, and event catalog governance.
-
-## Sync-to-Async Migration
-
-- Identify synchronous call chains that block on external dependencies; candidates for event extraction.
-- Start with non-critical paths (notifications, analytics) before migrating transactional flows.
-- Run synchronous and asynchronous paths in parallel during migration; deprecate sync after validation.
-
-## Schema Evolution — ED-R06
-
-- Prefer additive changes: add optional fields with defaults over removing or renaming fields.
-- Maintain backward compatibility for at least 2 major release cycles.
-- Use schema registry compatibility modes: BACKWARD (consumers tolerate new fields), FORWARD (producers tolerate old consumers), FULL (both).
-
-## Versioning Strategy
-
-- Embed version in the event envelope: `event-version: "1.2.0"`.
-- Use semantic versioning for schema changes: major (breaking), minor (additive), patch (fixes).
-- Maintain a version mapping table for migration paths between major versions.
-
-## Event Catalog Governance — ED-R07
-
-- Register every event type in a centralized catalog with ownership, domain, and retention metadata.
-- Require catalog entry before publishing a new event type to any environment.
-- Review catalog quarterly; archive unused events after stakeholder confirmation.
-
-## Deprecation Process
-
-- Mark deprecated events with `deprecated: true` in the catalog and schema registry.
-- Maintain deprecated events for a minimum of 6 months or 2 release cycles, whichever is longer.
-- Monitor consumer usage of deprecated events; notify owning teams when consumers remain.
-
-## Composable Applicability
-
-| Composable | Guidance |
-|---|---|
-| Modular Monolith | Schema evolution within module; catalog is intra-process. |
-| Distributed Modules | Cross-module schema coordination; shared catalog required. |
-| Microservices | Per-domain event catalog; schema registry as shared infrastructure. |
-| Serverless | Managed schema registry; versioning enforced by platform. |
-| Edge Computing | Local schema cache with periodic sync from central catalog. |
-
-## ADR References
-
-- **ADR-0015**: Schema evolution and versioning policy.
-- **ADR-0079**: Event catalog governance and lifecycle management.
-
----
-
-[Back to Event-Driven Profile](./README.md)

package/rulesets/topologies/event-driven/fixtures/invalid.topology.config.json

@@ -1,12 +0,0 @@
-{
-  "topology": "event-driven",
-  "strictAsyncApi": false,
-  "transactionalOutbox": false,
-  "deadLetterQueue": false,
-  "hasOrderingGuarantee": false,
-  "hasIdempotencyKey": false,
-  "hasBackwardCompatibleSchema": false,
-  "hasRetentionPolicy": false,
-  "hasEventCorrelation": false,
-  "hasConsumerGroupRegistry": false
-}

package/rulesets/topologies/event-driven/fixtures/valid.topology.config.json

@@ -1,12 +0,0 @@
-{
-  "topology": "event-driven",
-  "strictAsyncApi": true,
-  "transactionalOutbox": true,
-  "deadLetterQueue": true,
-  "hasOrderingGuarantee": true,
-  "hasIdempotencyKey": true,
-  "hasBackwardCompatibleSchema": true,
-  "hasRetentionPolicy": true,
-  "hasEventCorrelation": true,
-  "hasConsumerGroupRegistry": true
-}

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

@@ -1,36 +0,0 @@
-# Guia de Adopcion, Operacion y Evolucion Event-Driven
-
-> **Navegacion Bilingue:** [English Version](./maturity.md)
-
-## Adoption
-
-Adopte esta topologia cuando bounded contexts, modulos o servicios deban coordinar sin acoplamiento sincrono fuerte. Comience con contratos de eventos explicitos, publicacion confiable mediante Transactional Outbox y diseno de consumidores idempotentes.
-
-## Operations
-
-Opere uno o mas brokers de mensajes o buses de eventos. Monitoree la correlacion de flujo de eventos, lag de consumidores, profundidad de dead-letter queue y evidencia de replay como parte de la validacion normal de arquitectura.
-
-## Security
-
-Autorice la produccion y consumo de eventos en las fronteras del broker y la aplicacion. Nunca incruste datos sensibles en payloads de eventos; use identificadores de referencia y un plano de datos seguro para la recuperacion de payloads.
-
-## Resilience
-
-Disene consumidores para reintentos idempotentes, escalamiento a dead-letter para eventos no procesables y tolerancia a evolucion de schema. Prefiera redistribucion gestionada por broker sobre bucles de reintento a nivel de aplicacion.
-
-## Patterns and Anti-Patterns
-
-Use contratos AsyncAPI explicitos, Transactional Outbox para publicacion confiable, Dead Letter Queues para manejo de mensajes fallidos y versionado de eventos con compatibilidad hacia atras. No comparta internos de dominio a traves de eventos, use eventos para orquestacion de workflows ni asuma entrega en orden sin secuenciacion explicita.
-
-## Evolution
-
-Migre a integracion event-driven solo cuando la coordinacion asincrona este justificada por requisitos de workflow de negocio. Preserve contratos de eventos y registros de schema para que la migracion de consumidores siga siendo deliberada.
-
-## Validation Checklist
-
-- Valide la configuracion de topologia con `topology.config.schema.json` y ambos fixtures.
-- Ejecute la evaluacion Native y OPA mediante el plano de control compartido.
-- Confirme ADRs aprobados, guia bilingue y pruebas positivas y negativas reproducibles.
-
----
-[Volver al Perfil Event-Driven](./README.es.md)

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

@@ -1,36 +0,0 @@
-# Event-Driven Adoption, Operations, and Evolution Guide
-
-> **Bilingual Navigation:** [Version en Espanol](./maturity.es.md)
-
-## Adoption
-
-Adopt this topology when bounded contexts, modules, or services must coordinate without tight synchronous coupling. Start with explicit event contracts, reliable publication via Transactional Outbox, and idempotent consumer design.
-
-## Operations
-
-Operate one or more message brokers or event buses. Monitor event flow correlation, consumer lag, dead-letter queue depth, and replay evidence as part of normal architecture validation.
-
-## Security
-
-Authorize event production and consumption at the broker and application boundaries. Never embed sensitive data in event payloads; use reference identifiers and a secure data plane for payload retrieval.
-
-## Resilience
-
-Design consumers for idempotent retry, dead-letter escalation for unprocessable events, and schema evolution tolerance. Prefer broker-managed redelivery over application-level retry loops.
-
-## Patterns and Anti-Patterns
-
-Use explicit AsyncAPI contracts, Transactional Outbox for reliable publication, Dead Letter Queues for failed message handling, and event versioning with backward compatibility. Do not share domain internals through events, use events for workflow orchestration, or assume in-order delivery without explicit sequencing.
-
-## Evolution
-
-Move to event-driven integration only when asynchronous coordination is justified by business workflow requirements. Preserve event contracts and schema registries so that consumer migration remains deliberate.
-
-## Validation Checklist
-
-- Validate the topology configuration against `topology.config.schema.json` and both fixtures.
-- Run Native and OPA policy evaluation through the shared control plane.
-- Confirm approved ADRs, bilingual guidance, and reproducible positive and negative tests.
-
----
-[Back to Event-Driven Profile](./README.md)