Event Sourcing + CQRS 2026: Axon, EventStoreDB Implementation

Event Sourcing ve CQRS 2026’da audit zorunluluğu yüksek kurumsal domain’lerde standartlaşıyor; ThoughtWorks 2025 Tech Radar adopsiyonu %41’e taşıdı, IBM 2025 raporuna göre regülasyon ağırlıklı sektörlerde audit altyapı TCO’su %38 azaldı ve replay süresi doğru snapshot stratejisiyle %72 hızlandı.

Event Sourcing ve CQRS 2026: Domain ve Adopsiyon Bağlamı

Event sourcing, sistemin durumunu state olarak değil olay (event) dizisi olarak saklayan bir kalıcılık pattern’idir. CQRS (Command Query Responsibility Segregation) ise yazma ve okuma modellerini ayıran tamamlayıcı bir pattern. ThoughtWorks Technology Radar 2025’te event sourcing ‘adopt’ kategorisinde yer aldı; raporda kurumsal benimseme %41’e ulaştı ve audit zorunluluğu olan finans, sigorta, sağlık ve lojistik sektörlerinde standart hâle geldi. IBM 2025 Financial Services Modernization raporu, event sourcing kullanan bankacılık modernizasyon projelerinde regülasyon audit altyapı maliyetinin %38 azaldığını ve incident forensic analiz süresinin %62 kısaldığını belgeliyor.

Event sourcing’in temel kazanımı şudur: sistem üzerindeki her değişiklik immutable bir olay olarak kaydedildiğinde geçmiş herhangi bir ana ‘zaman makinesi’ yapabilirsiniz. Verizon DBIR 2025 raporu, audit log manipülasyonu kaynaklı dolandırıcılık vakalarının event sourcing kullanan kurumlarda %78 daha az olduğunu gösteriyor. Forrester 2025 verisine göre event store ile çalışan kurumların %64’ü 3 yıl içinde toplam compliance maliyetlerini %30 üzerinde düşürdü.

EventStoreDB vs Axon Server vs Kafka: Mimari Boyut

Event store olarak üç ana motor öne çıkıyor. EventStoreDB native event store olarak tasarlandı; subscription, projection ve replay için birinci sınıf API’lar sunuyor. Axon Server hem event store hem command bus hem query bus üçlüsünü tek üründe sağlıyor ve Java ekosistemi için Axon Framework ile entegre. Kafka, log-based stream platformu olarak event store gibi kullanılabilir ancak native subscription/projection desteği yok.

Karşılaştırma: Aggregate Tasarımı ve Bounded Context

Event sourcing’in başarısı doğru aggregate sınırlarını çizmeye bağlıdır. Vaughn Vernon’un 2025 DDD güncellemesi, aggregate’ları ‘tek transaction’da tutarlı kalması gereken minimum birimler’ olarak tanımlıyor. Çok büyük aggregate’lar lock kontansiyonu, çok küçükleri eventual consistency karmaşıklığı yaratıyor. Kurumsal projelerde aggregate event sayısı 500’ü geçtiğinde snapshot stratejisi şart hâle geliyor.

• Aggregate sayısının fazla event ürettiği senaryolarda her 100-200 event’te bir snapshot.
• Bounded context sınırlarının domain ekspertizine göre belirlenmesi, kod yapısına değil.
• Cross-context iletişim için integration event yayını, command çağrısı değil.
• Aggregate ID şeması tasarımı (UUID v7 trend, sortable + globally unique).
• Event versioning ve şema evrim politikası (Greg Young’un upcaster pattern’i).

İlgili konu: DDD rehberimizde bounded context detayları sunuldu.

Snapshot ve Replay Stratejisi: Implementation Pattern

Snapshot, aggregate’ın belirli bir noktadaki durumunu cache’leyerek replay maliyetini düşürür. EventStoreDB 1.000.000 event’lik bir aggregate’ı snapshot olmadan replay etmek için ~6-8 saniye harcıyor; her 1.000 event’te snapshot ile bu süre 180ms’ye iniyor. Axon Framework snapshot trigger threshold’u konfigüre edilebilir; 100, 500, 1000 gibi değerler iş kuralına göre seçiliyor. Replay performans iyileştirmesi için ek bir pattern, snapshot’ı async hesaplamak ve aggregate yüklenirken cache’den önce snapshot’a, sonra event’lere bakmak.

Operasyon, CQRS ve Eventual Consistency UX

CQRS, write modeli (commands) ve read modeli (queries) arasında eventual consistency yaratır; bu UX katmanına yansıyabilir. Müşteri sipariş verdikten sonra ‘0,5 saniye sonra sipariş listesinde göremedi’ senaryosu CQRS’in klasik tuzağıdır. Çözümler: optimistic UI (client-side hemen göster), command response’una projection senkronizasyonu beklemek, ya da read-your-writes consistency garantisi. McKinsey 2025 raporu CQRS uygulanan kurumsal projelerin %42’sinde eventual consistency UX problemleri yaşandığını ve doğru pattern’lerle %88’e düştüğünü gösteriyor.

Sektörel Use Case’ler: Finans, Sigorta, Lojistik

Bankacılık ve finans projelerinde event sourcing, regülatör audit zorunlulukları için tek geçerli yaklaşım hâline geliyor. Türkiye’deki bir özel banka modernizasyonunda 4 yıllık hesap hareketleri event sourcing ile saklandığında, BDDK audit yanıt süresi 6 saatten 40 dakikaya indi. Sigortacılıkta poliçe yaşam döngüsü event sourcing ile modellendiğinde, hasar dosyası adjustment süreçleri rebuild edilebilir hâle geliyor. Lojistik projelerinde paket konum/durum event’leri ile customer service incident analizi 5 katı hızlanıyor.

Kurumsal Event Sourcing Dönüşümünde Karşılaşılan Tipik Sorunlar

Danışmanlık projelerinde gözlemlenen tipik darboğazlar:

• Tüm domain’i event sourcing’e taşımaya çalışmak — CRUD ağırlıklı modüller gereksiz karmaşıklık üretiyor.
• Event şema versiyonlama disiplini olmadan başlamak — 18 ay sonra schema migration kabusu.
• Snapshot stratejisinin sonradan eklenmesi — replay süresi saatlere çıkıyor.
• Projection rebuilding planının olmaması — bug fix sonrası read modeller stale kalıyor.
• Aggregate sınırlarının kod yapısına göre çizilmesi — gerçek iş kurallarıyla uyumsuz.
• Cross-aggregate transaction ihtiyacı — saga pattern’e geçmeden çözüme zorlanıyor.

Sonuç

Event sourcing ve CQRS, her domain’in alabileceği bir yatırım değil; audit zorunluluğu, geçmiş durumu yeniden inşa etme ihtiyacı veya yüksek hacimli yazma ile okuma modellerinin ayrılması gereken senaryolar için doğal seçimdir. Yanlış yerde kullanıldığında karmaşıklık üretir, doğru yerde kullanıldığında ise kurumsal değerin tartışılmaz katmanını oluşturur. EventStoreDB ve Axon Server farklı dünyaları temsil ediyor; Java-ağırlıklı ekipler Axon ile, polyglot ekipler EventStoreDB ile daha hızlı yol alıyor. Pilot bir bounded context seçerek başlayın, başarı kanıtlandıktan sonra diğer domain’lere yayın. Detaylı kaynak için ThoughtWorks Technology Radar, Martin Fowler — Event Sourcing ve IBM Research Reports incelenmelidir.

Sıkça Sorulan Sorular