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 and Frank Steimle - Digital Frontiers (Consultants, 15+ years)

💡 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