Event Flowing Sessions

Event Flowing is a collaborative methodology for designing, building, and testing event-driven systems using EventFlow. It brings together cross-functional teams to create executable specifications through iterative sessions.

The Core Principle

The diagram is your thinking tool.

Unlike traditional approaches where diagrams are drawn first and then translated to code (where they inevitably drift), Event Flowing makes the diagram an active part of your design process:

1. Write the flow in natural language
2. Watch the diagram evolve as you type
3. Think through the visualization together
4. Refine until the team agrees

The diagram isn't just output - it's where you think through your design.

Remote Sessions

Event Flowing sessions happen remotely. The team joins a video call, and the developer shares their screen showing both the flow file and the live diagram.

The developer (Alex) acts as the "scribe" - writing EventFlow code while the discussion continues over voice. With watch mode enabled, diagrams update automatically:

$ eventflow watch order.flow

  EventFlow v1.0.0

  ➜  Editor:   http://localhost:5173/
  ➜  Diagram:  http://localhost:5173/diagram
  ➜  Tests:    http://localhost:5173/tests

  Watching for changes...

Everyone sees the same diagram. Everyone thinks through the same visualization.

The Team

Event Flowing works best with a cross-functional team:

Role	Focus	Key Questions
Product Manager	Business requirements	"What should happen when...?"
Developer	Technical implementation	"How do we handle...?"
QA Engineer	Edge cases & quality	"What if...?" / "What could go wrong?"
Designer	User experience	"What does the user see?"

The Flow

A typical Event Flowing engagement follows this pattern across 5 sessions:

Session Types

Session 1-2: Event Flowing (Full Team)

• Identify actors and events together
• Write the flow in natural language
• Think through the diagram as it evolves
• Discuss data and context step by step
• Clarify edge cases (but don't solve them yet)

Session 3: Edge Case Discovery (QA + Dev)

• Systematically identify failure scenarios
• Write test cases first (.test.flow)
• Use assume: and observe: for precise testing
• Failing tests become implementation targets

Session 4: Implementation (Dev Solo)

• Update flow to handle edge cases
• Add guards, OR guards, otherwise branches
• Turn failing tests green
• Write PHP bindings (guard/action/event classes)

Session 5: Review (Full Team)

• Run full test suite with coverage
• Review generated diagrams
• Validate living documentation
• Ship it!

Example: E-commerce Checkout

This guide walks through building an e-commerce checkout flow across 5 sessions:

• Session 1: Discovery - Identifying actors, events, and data
• Session 2: Happy Path - Writing the flow with context
• Session 3: Edge Cases - QA + Dev discover failure scenarios
• Session 4: Implementation - Dev implements guards and bindings
• Session 5: Review - Final testing and ship

The Team for This Example

Throughout these sessions, you'll follow four team members:

• Sarah (Product Manager) - Owns the business requirements, makes scope decisions
• Alex (Developer) - Writes the flows and implements PHP bindings
• Jordan (QA Engineer) - Challenges assumptions, discovers edge cases, writes tests
• Maya (Designer) - Focuses on user experience and state visibility