About this chapter
Chapter 4 introduced domain events - a record of something that happened in the business. Chapter 6 split writes from reads with a first look at CQRS. This chapter puts events at the center of the design. You'll learn what event-driven architecture is and how a message broker lets parts of a system talk without knowing about each other, the crucial difference between a command (an intent) and an event (a fact), and two ways to coordinate a multi-step process: choreography and orchestration. Then we go deeper: event sourcing (store the events, not the current state), building read models for full CQRS, and the saga pattern for transactions that span several services. These are advanced ideas, so every lesson starts from the problem and keeps the PHP small.
Lessons from courses
- 1 What is event-driven architecture? How publish/subscribe replaces direct calls between services, what a message broker does, and how events decouple senders from receivers in time and space.
- 2 Events vs commands Events vs commands: a command is an intent one handler can reject; an event is a past-tense fact many can react to and cannot refuse. Learn the difference.
- 3 Choreography vs orchestration Choreography vs orchestration: coordinate a multi-step process with services reacting to events, or a coordinator directing the steps. Trade-offs inside.
- 4 Event sourcing Event sourcing stores the sequence of events as the source of truth instead of current state, and rebuilds state by replaying them. Benefits, costs, PHP example.
- 5 Read models and CQRS Read models and CQRS: build query-optimized projections from an event stream. This is full CQRS - separate write and read models, rebuildable by replay.
- 6 The saga pattern The two ways to run a saga - choreography and orchestration - plus compensating actions and why consistency across services is eventual, not instant.