Event Sourcing, CQRS, and Projections

Event sourcing and CQRS are powerful patterns, but they should not be treated as default markers of architectural maturity. They introduce permanent contracts, replay obligations, extra operational state, and more demanding mental models. They are strongest where the domain genuinely benefits from those trade-offs.

Read the lessons in order. The first introduces event sourcing fundamentals and the implications of making an event log the system of record. The second explains CQRS as a separation of write-side rule enforcement from read-side query models. The third focuses on projections and materialized views, which are often useful even without full event sourcing. The fourth makes the limiting case explicit by explaining when event sourcing is overkill.

If your team uses the words event sourcing or CQRS as if they automatically mean “more advanced,” Chapter 12 is where those patterns need to become concrete, bounded, and decision-oriented.

In this section

• Event Sourcing Fundamentals
  A practical lesson on event sourcing as a system-of-record pattern, including replay, aggregate reconstruction, permanence, and the operational cost of event history.
• CQRS Fundamentals
  A practical lesson on Command Query Responsibility Segregation, including when separate write-side and read-side models help and when CQRS becomes architecture theater.
• Projections and Materialized Views
  A practical lesson on turning event streams into usable read models, including replay safety, eventual consistency, and the difference between projections and source-of-truth state.
• When Event Sourcing Is Overkill
  A practical lesson on recognizing when event sourcing adds more permanence and operational burden than the domain actually needs.