Event Sourced Transformation in Financial Systems
summary
A team migrates a large legacy three‑tier app into CQRS plus event sourcing by splitting the middle tier into small domain services that append to an event store append-only streams and emit read models; uses clustered storage, queues, JSON events and upcast on deserialize for versioning. Conflict cases become explicit events (calendar collisions produce a conflict event) and bad data is fixed by reversing transactions or reprojection. A production peer‑review system proved rollback and auditability work in practice and speeds debugging and testing.
AI-written summary · about
chapters (18)
- 0:00Introduction
- 1:16Why event sourcing matters
- 3:04Complexity in software systems
- 7:27Event sourcing in financial systems
- 11:04Debugging with event history
- 16:50Atomic aggregates and invariants
- 21:28Conflict resolution in domains
- 25:29CQRS and domain-driven design
- 28:01Migrating legacy to event sourcing
- 30:11When to use event sourcing
- 32:21Benefits of event-sourced systems
- 34:53Productivity with event sourcing
- 36:50Q&A on microservices
- 40:16Versioning in distributed systems
- 44:15Replication and consistency
- 46:46Handling bad events
- 48:43Event sourcing in master data
- 50:35Summary and takeaways
related talks
52mEvent-driven vs event sourcing: what's really the difference?
48mEvent Sourcing - what could possibly go wrong?
01h 25mBuilding microservices with event sourcing and CQRS
01h 07mAn Architecture with CQRS and Event Sourcing
47mFrom C to Q, One Event at a Time: Event Sourcing in Pictures
54mEvent Sourcing
43mEvent Sourcing dealing with an eventful past
49mCQRS and Event Sourcing explained