Production'ı Bozmadan Breaking Change: Event Upcasting ve Schema Evolution

İlişkisel bir tabloda `customer_name` kolonunu `full_name` yapmak için bir migration yazıp tüm satırları güncellersiniz; eski şema bir daha görünmez. Event sourcing'de durum farklı. Event'ler değişmez (immutable) kabul edilir, çünkü denetim izi, yeniden oynatma (replay) ve projeksiyon yeniden üretimi bu değişmezliğe dayanır. 2022'de yazılmış bir `OrderPlaced` event'i, 2026'da yeni bir okuma modeli kurarken yeniden okunacak.

Sonuç: kodunuz aynı event tipinin birden fazla tarihsel biçimiyle karşılaşır. Aggregate'i yeniden kurarken v1, v2 ve v3 biçimleri aynı akışta yan yana durabilir. Bunu yönetmezseniz deserializasyon hataları ya da daha kötüsü, sessizce `null` gelen alanlar yüzünden yanlış hesaplanan bakiyeler alırsınız. Anti-pattern: event sınıfını doğrudan domain nesnesi olarak kullanıp üzerinde refactor yapmak; IDE'nin 'rename' tuşu eski event'leri bozar.

Son on iki ayda event sourcing araçlarında en büyük hareket, tutarlılık sınırının yeniden tanımlanması oldu. Axon Framework 5.0, Ekim 2025'te Dynamic Consistency Boundary (DCB) desteğiyle çıktı; DCB'de event'ler tek bir stream'e değil etiketlere bağlanıyor ve her işlem kendi tutarlılık kapsamını bir sorguyla tanımlıyor. Axoniq Mayıs 2026'da 'aggregate'in devri bitti' iddiasını açıkça savundu, Ağustos 2026'daki Axon Server 2026.1.0 DCB bağlamları için çok katmanlı depolama getirdi, 6 Ekim 2026'daki Axon Framework 5.4.0 ise event sourcing üzerine kurulu dayanıklı workflow'larla Saga'lardan çıkış yolu sundu. dcb.events topluluk listesinde artık Java, C#, Go, Python ve Rust dahil birçok dilde DCB uygulaması var.

Şema evrimi açısından önemli ayrıntı: Axon 5.0'da upcaster'lar geçici olarak kaldırılmıştı; dokümantasyon bunların 5.2 ile döneceğini söylüyordu ve 5.2 sürüm notları 'message transformation / upcasting' çalışmasını içeriyor. Marten 9.x dokümantasyonu CLR tipleri ya da ham JSON üzerinden upcast'i anlatıyor. Kleppmann ve Riccomini'nin Designing Data-Intensive Applications kitabının Şubat 2026'da çıkan ikinci baskısı, şema evrimi ve kodlama konusunda güncel temel referans.

Her değişiklik eşit değil. Kırıcı olmayan (non-breaking) değişiklikler: varsayılan değeri olan opsiyonel bir alan eklemek, okuyucuların görmezden gelebileceği yeni bir alan eklemek. Kırıcı (breaking) değişiklikler: alan adını değiştirmek, alanın tipini değiştirmek (string fiyatı integer kuruşa çevirmek gibi), bir alanı ikiye bölmek (`address` yerine `street` ve `city`), bir alanın anlamını değiştirmek ve event'i yeniden adlandırmak.

En sinsi olan anlam değişikliğidir. `amount` alanı v1'de KDV dahil, v2'de KDV hariç tutuluyorsa şema aynı görünür ama her eski event yanlış yorumlanır. Pratik kural: alan adı aynı kalıp anlamı değişiyorsa bunu kırıcı değişiklik sayın ve ya yeni bir alan adı kullanın ya da versiyon numarasını artırıp upcaster yazın. Kırıcı olmayan değişiklikler için de 'tolerant reader' (hoşgörülü okuyucu) ilkesini uygulayın: bilinmeyen alanları yok sayın, eksik alanlara açık varsayılan verin.

Upcaster, eski versiyondaki bir event'i bir sonraki versiyona çeviren saf bir fonksiyondur. Depodaki veri değişmez; dönüşüm event okunurken, deserializasyondan önce veya hemen sonra uygulanır. Zincir halinde çalışır: v1 → v2 → v3. Böylece uygulama kodu yalnızca en güncel biçimi bilir.

Örnek: `PriceChanged` v1'de `price: "129.90"` string olarak, v2'de `priceMinor: 12990` ve `currency: "TRY"` olarak tutuluyor. Upcaster v1 event'i okuyunca fiyatı kuruşa çevirir, para birimi için o dönemde geçerli olan sabit değeri ekler, versiyonu 2 yapar. Axon Framework 4'te bunun için upcaster zinciri vardı; 5.0'da geçici olarak kaldırılan upcaster'lar 5.2 ile 'message transformation' çatısı altında geri geldi, bu yüzden Axon 5'e geçen ekiplerin sürüm notlarını dikkatle okuması gerekiyor. Marten 9.x'te upcaster'lar fonksiyon ya da sınıf olarak tanımlanabiliyor ve ham JSON üzerinde dönüşüme izin veriliyor; böylece eski CLR sınıflarını kod tabanında tutmak zorunda kalmazsınız. Marten dokümantasyonu async upcaster'larda N+1 sorgu riskine karşı da uyarıyor. Kural: upcaster deterministik olmalı ve dış servise gitmemeli; replay'in her seferinde aynı sonucu üretmesi buna bağlı.

Upcasting tek seçenek değil. Yeni event tipi: değişiklik kavramsal olarak farklıysa (ör. `OrderShipped` yerine `OrderPartiallyShipped` ve `OrderFullyShipped`) eskisini bırakıp yeni tip tanımlamak daha dürüsttür; okuyucular her iki tipi de işler. Weak schema: event'i katı bir sınıfa bağlamadan, alan bazında eşleyerek okumak; ekleme türü değişikliklerde migration ihtiyacını azaltır ama tip güvenliğini zayıflatır.

Kopyala-dönüştür (copy-transform): tüm akışı yeni bir depoya, dönüştürülmüş haliyle kopyalayıp trafiği oraya çevirmek. Bu yöntem upcaster zinciri çok uzadığında (ör. 6-7 versiyon) veya kişisel verinin silinmesi gerektiğinde mantıklıdır, ama operasyonel olarak ağırdır ve 'event'ler değişmez' ilkesini bilinçli olarak esnetir. Greg Young'ın 'Versioning in an Event Sourced System' kitabı bu seçenekleri karşılaştıran temel referans. Pratik sıralama: önce kırıcı olmayan değişiklik, sonra upcaster, son çare kopyala-dönüştür. DCB kullanan sistemlerde bir ek nokta var: event'ler etiketlerle sorgulandığı için bir alanı ya da etiketi yeniden adlandırmak yalnızca okumayı değil, tutarlılık sorgularını da etkiler; etiket şeması da versiyonlanması gereken bir sözleşmedir.

Bir event yalnızca kendi servisinizin içinde okunuyorsa upcaster yeterli olabilir. Ama event Kafka, RabbitMQ veya benzeri bir broker üzerinden başka ekiplerin servislerine yayınlanıyorsa, o event artık bir API sözleşmesidir. Burada iç event'ler (domain event) ile dışa açılan event'leri (integration event) ayırmak önemli; iç event'i özgürce evriltip dış event'i daha yavaş ve kontrollü değiştirirsiniz.

Schema registry (şema kayıt sistemi) kullanan ekipler Avro veya Protobuf şemalarına uyumluluk kuralı koyar: geriye dönük uyumluluk (yeni okuyucu eski veriyi okuyabilir) ya da ileriye dönük uyumluluk (eski okuyucu yeni veriyi okuyabilir). Kırıcı bir değişiklik gerekiyorsa genelde yeni bir topic veya yeni bir event versiyonu açılır ve iki versiyon belli bir süre (ör. bir çeyrek) birlikte yayınlanır. Anti-pattern: tüketicilerin kim olduğunu bilmeden alanı silmek ve sorunu bir başka ekibin gece alarmından öğrenmek.

Upcaster'ların en büyük riski, yalnızca yazıldıkları gün test edilmeleri. Sağlam bir pratik: her event versiyonu için gerçek üretimden alınmış (anonimleştirilmiş) örnek JSON'ları `fixtures/events/OrderPlaced/v1.json` gibi dosyalarda saklamak ve CI'da her fixture'ı en güncel versiyona upcast edip aggregate'i kurmak. Yeni bir versiyon eklendiğinde eski fixture'lar silinmez; zincirin tamamı her build'de test edilir.

Operasyon tarafında iki gösterge işe yarar: akışlarda hâlâ hangi versiyonların bulunduğu (ör. `OrderPlaced` event'lerinin yüzde kaçı v1) ve upcasting'in okuma süresine eklediği gecikme. Eski bir versiyon artık hiçbir aktif akışta yoksa veya arşivlenmiş akışlarda kalmışsa, o upcaster emekliye ayrılabilir. AI ajanıyla kod yazan ekipler için ekstra kural: event sınıflarına dokunan her değişiklik, ajan talimat dosyasında 'yeni versiyon + upcaster + fixture' üçlüsünü zorunlu kılmalı; yoksa ajan bir rename ile geçmişi bozabilir.