Summary: Event-Driven Architecture

Event-driven architecture isn't just a technical strategy – it's a shift in how we model behavior, decisions, and outcomes.

In this walkthrough, you've seen how each part of such a system fits together:

1. Interaction starts with a command or query

   The user expresses an intent or asks for information – never both at once.

2. Commands are handled by domain logic

   Command handlers take the current state, apply business rules, and emit events.

3. Events are the outcome of decisions

   They represent what happened – facts, not wishes – and are immutable.

4. Events are stored in streams

   Each stream captures the full history of an entity, not just its current state.

5. Events are published

   Other parts of the system subscribe to them and react asynchronously.

6. Projections build read models

   These are tailored views of the data – optimized for reading and UI usage.

7. Read models are eventually consistent

   They lag slightly behind, but enable performance, scalability, and resilience.

8. Events form the single source of truth

   You can always rebuild, re-understand, or re-derive any part of the system.

Together, these steps create a system that models processes, not just data. A system where behavior is explicit, decisions are traceable, and logic follows the real world.