F02 — Domain & Capability Discovery

Phase 2 — Event Storming & Bounded Contexts

Objetivo

Comprender el negocio modelando eventos, comandos, actores, politicas, agregados y bounded contexts. Producir un mapa del dominio que guie las decisiones de arquitectura AI/deterministica.

---

1. Event Storming — Guia Rapida

Que es

Workshop colaborativo donde el equipo modela un proceso de negocio usando sticky notes (fisicos o digitales). Produce un flujo temporal de eventos que revela la complejidad real del dominio.

Elementos del Event Storming

Elemento	Color	Pregunta que responde	Ejemplo
Domain Event	Naranja	Que paso? (pasado)	“Pedido Creado”, “Pago Confirmado”
Command	Azul	Que lo disparo?	”Crear Pedido”, “Procesar Pago”
Actor	Amarillo	Quien lo hizo?	”Cliente”, “Agente AI de Soporte”
Policy	Lila	Que regla aplica?	”Si monto > $1000, requiere aprobacion”
Read Model	Verde	Que info necesita el actor?	”Dashboard de pedidos”, “Historial”
External System	Rosa	Que sistema externo participa?	”Pasarela de pago”, “LLM API”
Hotspot	Rojo	Donde hay confusion o conflicto?	”No sabemos quien aprueba descuentos”

Proceso (2-4 horas)

1. CHAOTIC EXPLORATION (30 min)
   → Todos escriben domain events en naranja, los pegan en la pared
   → No hay orden, no hay critica, solo volumen

2. TIMELINE (30 min)
   → Ordenar eventos de izquierda a derecha cronologicamente
   → Identificar duplicados, resolver conflictos

3. REVERSE NARRATIVE (30 min)
   → Para cada evento: que comando lo disparo? que actor ejecuto el comando?
   → Agregar commands (azul) y actors (amarillo)

4. POLICIES & RULES (20 min)
   → Para cada transicion: hay alguna regla? automatica o manual?
   → Agregar policies (lila)

5. EXTERNAL SYSTEMS (15 min)
   → Que sistemas externos participan?
   → Agregar external systems (rosa) — incluir LLM APIs, MCP servers

6. BOUNDED CONTEXTS (30 min)
   → Agrupar clusters de eventos con fronteras claras
   → Nombrar cada cluster = un bounded context candidato

7. AI OVERLAY (20 min) ← Especifico de este framework
   → Para cada bounded context: necesita IA? (Nivel 0-3)
   → Marcar con tag: [AI-L0], [AI-L1], [AI-L2], [AI-L3]

2. Bounded Context Template

project/F02_domain/bounded_contexts.yaml

bounded_contexts:
  - name: "Order Management"
    description: "Ciclo de vida completo del pedido"
    ai_level: 0  # Deterministic CRUD
    actors: ["Customer", "Sales Agent"]
    core_events:
      - "OrderCreated"
      - "OrderApproved"
      - "OrderShipped"
      - "OrderDelivered"
    aggregates: ["Order", "OrderLine"]
    policies:
      - "Orders > $1000 require manager approval"
    external_systems: ["Payment Gateway", "Shipping API"]

  - name: "Customer Support"
    description: "Atencion al cliente con AI assistant"
    ai_level: 2  # Service + MCP Tools
    actors: ["Customer", "AI Support Agent", "Human Escalation Agent"]
    core_events:
      - "TicketOpened"
      - "AIResponseGenerated"
      - "EscalatedToHuman"
      - "TicketResolved"
    aggregates: ["Ticket", "Conversation"]
    policies:
      - "Refunds > $500 always escalate to human"
      - "AI confidence < 70% triggers escalation"
    external_systems: ["LLM API", "Knowledge Base (RAG)", "CRM"]
    mcp_servers: ["crm-server", "knowledge-base-server"]

3. Capability Map Template

project/F02_domain/capability_map.yaml

capabilities:
  - name: "Product Search"
    bounded_context: "Product Catalog"
    ai_level: 1  # RAG
    priority: "must-have"
    description: "Busqueda semantica de productos por lenguaje natural"

  - name: "Order Processing"
    bounded_context: "Order Management"
    ai_level: 0  # Deterministic
    priority: "must-have"
    description: "CRUD de pedidos, validaciones, estados"

  - name: "Customer Support Chat"
    bounded_context: "Customer Support"
    ai_level: 2  # MCP Tools
    priority: "should-have"
    description: "Chat con AI que consulta CRM y knowledge base"

4. Domain Glossary Template

Termino	Definicion	Bounded Context	Sinonimos a evitar
Order	Solicitud de compra de un cliente	Order Management	”Pedido”, “Request” (usar solo “Order”)
Ticket	Caso de soporte abierto por cliente	Customer Support	”Issue”, “Case” (usar solo “Ticket”)
Agent	Agente AI de soporte (NO persona)	Customer Support	Evitar “bot”, “assistant”

5. AI Overlay — Decision por Bounded Context

Para cada bounded context, aplicar el arbol de decision del Manifesto (§7):

¿El contexto necesita entender lenguaje natural?
├── NO → Nivel 0: Deterministico
└── SI → ¿Solo buscar en documentos?
    ├── SI → Nivel 1: RAG
    └── NO → ¿Ejecutar acciones en otros sistemas?
        ├── SI sin razonamiento multi-paso → Nivel 2: MCP Tools
        └── SI con razonamiento complejo → Nivel 3: Agente autonomo

6. Checklist de Salida — Gate 2

• Event Storming realizado (o equivalente de modelado de dominio)
• Bounded contexts identificados y nombrados
• Capability map con prioridades
• Domain glossary con terminos clave (evitar ambiguedad)
• AI Overlay: nivel AI asignado a cada bounded context
• Hotspots documentados y resueltos (o escalados)

Entregables minimos por track

Artefacto	Solo	Lean	Full
capability_map.yaml	3-5 capabilities	Completo	Completo + priorizado
Bounded Contexts	Informal (en CLAUDE.md)	bounded_contexts.yaml	YAML + diagrama
Domain Glossary	En CLAUDE.md	Tabla markdown	YAML versionado
Event Storming	No requerido	Ligero (1h)	Completo (2-4h)
AI Overlay	Inline en config	Por bounded context	Formal con justificacion

Referencias

• CORE_F02_Product_Discovery_Requirements.md — discovery de producto
• framework/guides/AI_First_SDLC_Workflow_Guide.md — flujo completo
• Schema: scripts/schemas/capability_map.schema.json
• Skill: /f02_domain

---

AI-First Engineering Framework v6.5 — Phase 2: Domain & Capability Discovery