Thinking in Events
summary
Argues that modeling domain activity as events instead of CRUD yields clearer requirements and safer systems, using EventStorming on butcher paper with colored post‑its to discover events like patient admitted and patient transferred, then implementing event sourcing (EventStore) plus CQRS and projections (example using RavenDB), snapshotting to avoid long replays, and RabbitMQ or polling APIs for cross‑service delivery. Results: full audit trail, simpler given/when/then tests, ability to rebuild historical ward views, and workable eventual‑consistency tradeoffs.
AI-written summary · about
chapters (21)
- 0:00Start
- 8:30Ubiquitous Language
- 11:39Domain Experts
- 13:59The Commander of the Action
- 14:42External Events
- 16:13Questions
- 18:21Tips for Running this Meeting
- 20:21Back of a Napkin
- 28:09Database Triggers
- 32:11The Mental Pattern of a Snapshot Plan
- 33:36Command Query Separation
- 34:03Cqrs Command Query Responsibility Separation
- 37:18Adding for Example Reports to the System after It's Already in Production
- 38:02The Architecture
- 39:01Start of a Pipeline
- 39:18Mediator Pattern
- 40:15Fail To Apply Events
- 41:09Constructor of Encounters
- 41:41Projection Manager
- 43:49Eventual Consistency
- 52:35Links
related talks
43mEvent driven development
50mAn Introduction to CQRS and Event Sourcing Patterns
43mUnraveling the Threads: Event-Sourcing, CQRS, and Event-Driven Architecture
55mNavigating complexity in event-driven architectures: A domain-driven approach
38mEvery Event, Everywhere, All at Once
52mNavigating complexity in event-driven architectures: A domain-driven approach
51mThings I Wish I knew Before I Started with Event Sourcing
26mEvent-Sourcing your React-Flux applications