
ยท
Axoniq Conference 2025 Day 2: Consultant's Guide to Convincing Customers About Event Sourcing
Frank and Florian from Digital Frontiers reveal the often-overlooked benefits of event sourcing that help convince skeptical customers. Learn about evolvability, seamless testing, and day-one data features, plus debunk common misconceptions.
๐ฏ Speakers:
Florian Pfleiderer - Senior Consultant, Digital Frontiers
Frank Steimle - Senior Consultant, Digital Frontiers
๐ก The Real Title:
"A Consultant's Guide to Convincing Your Customer They Actually Want Event Sourcing"๐ Four Hidden Strengths:
1๏ธโฃ Building Blocks as First-Class Citizens
Event modeling blueprint โ Code (1:1 translation)
Skip UML layer entirely
No abstraction overhead
Direct from business requirements to implementation
2๏ธโฃ Well-Defined Interfaces & Boundaries
Avoid "octopus code" (changes everywhere)
Add features without touching existing code
Premium subscription example: Just add events
Ports & adapters naturally enforced
3๏ธโฃ Testability Without Mocking
Given-When-Then = natural language in code
No repository mocking hell
No constructor mocking complexity
Isolated tests that don't interfere
New requirements = just add one event to test
4๏ธโฃ Day One Data Features
Build features on historical data TODAY
5-year badge? Available immediately via replay
New read models from existing events
Mobile optimization without new data capture
๐ซ Five Misconceptions Debunked:#1: Immutability = Can't Change
โ Wrong: Upcasting exists (like adding DB columns)
โ Right: Transform old events to new format#2: Eventual Consistency Unsuitable for Users
โ Wrong: Users need immediate feedback
โ Right: UX design solves this (Adam: "Non-issue")#3: CQRS Only for Analytics
โ Wrong: Just for reporting/scalability
โ Right: Flexibility for any use case#4: GDPR Incompatible
โ Wrong: Can't delete immutable events
โ Right: Encrypt & delete keys, or external PII store#5: Kafka = Event Sourcing
โ WRONG: Kafka is NOT an event store
โ Right: Event-driven (between services) โ Event sourcing (inside services)
๐ Example: Online Auction HouseTraditional Architecture Pain:
Seller entity across 3 layers
Add second address line = touch everywhere
Tests need mocking: ShipmentRepo, PaymentRepo, ReviewRepo
New requirement = change 100+ test locations
Event Sourcing Solution:
SellerRegistered event
PremiumSubscriptionStarted event
Add badge requirement? Replay UserRegistered events
New mobile UI? New read model from same events