Olay ve şema tasarımı: sözleşmeyi bozmadan evrilmek

Olay bir sözleşmedir, veri yapısından fazlası

Olay güdümlü mimaride bir servis, "sipariş oluşturuldu" gibi bir olayı yayımlar ve onu kimlerin tükettiğini bilmez. Bu gevşek bağlılık güçtür, ama bir bedeli vardır: olayın biçimi, yayımlayan ile tüm tüketiciler arasında fiilî bir sözleşmeye dönüşür. Alan adını değiştirmek, bir alanı kaldırmak ya da anlamını kaydırmak, haberi olmayan bir tüketiciyi bozabilir.

Bu yüzden olay tasarımı şu soruları birlikte yanıtlar: olay iş dünyasında neyi anlatıyor ve zaman içinde bozulmadan nasıl değişir? İlk soru adlandırma ve içerik kararlarını, diğeri şema yönetimini ilgilendirir.

İyi tasarlanmış bir olay, hangi servis tükettiğine bağlı olmadan tek başına anlaşılır; kötü tasarlanmış olay ise yalnızca onu yazan ekibin kafasındaki bağlamla çalışır.

Olayı adlandırmak ve sınırlarını çizmek

Olay, geçmişte gerçekleşmiş bir iş olgusudur. Bu nedenle geçmiş zaman kipiyle ve iş diliyle adlandırılır: SiparişOluşturuldu, ÖdemeReddedildi, SevkiyatYoldaBildirildi. Aşağıdaki ayrımlar sık karıştırılır:

• Olay ile komut. Komut bir istektir ve reddedilebilir ("ödemeyi al"); olay olmuş bir gerçektir ve geri alınamaz.
• İş olayı ile teknik değişiklik bildirimi. "SiparişTablosuGüncellendi" teknik bir ayrıntıyı yansıtır ve tüketiciye anlam taşımaz. "SiparişAdresiDeğiştirildi" ise iş anlamı taşır.
• Tek olay ile her şeyi kapsayan olay. Çok farklı nedenlerle tetiklenen genel bir "SiparişGüncellendi" olayı, tüketiciyi ne olduğunu çözmek için alanları karşılaştırmaya zorlar.

Ayrıntı düzeyi için ölçüt, tüketicinin vereceği karardır. Bir tüketici adres değişikliğine farklı, ürün eklenmesine farklı tepki veriyorsa bunlar ayrı olaylardır. Olayın hangi aggregate ya da iş sınırına ait olduğu da net olmalıdır; aksi halde birden çok servis aynı olayı yayımlamaya kalkar.

Olay ne kadar veri taşımalı?

En temel tasarım kararı, olayın içeriğidir. Başlıca yaklaşımlar şunlardır:

• Hafif (referans) olay: yalnızca kimlik ve neyin değiştiğini taşır. Tüketici ayrıntı gerekirse kaynak servisten sorgular. Şema küçük kalır, ama tüketiciler kaynak servise bağımlı hale gelir ve olay işlenirken veri değişmiş olabilir.
• Zengin (durum taşıyan) olay: tüketicinin ihtiyaç duyacağı verinin çoğunu içerir. Tüketici kaynak servisi çağırmadan çalışır; bağımsızlık artar. Karşılığında şema büyür, hassas verinin yayılma riski doğar ve alan eklemek daha sık sözleşme tartışması getirir.

Seçim, tüketicilerin bağımsızlık ihtiyacına göre yapılır. Kritik bir kuralı aklınızda tutun: olaya, bugün bilinen tüm olası tüketicinin her ihtiyacını koymak yerine olayın anlattığı olgunun kendisini ve onu anlamak için gereken bağlamı koyun.

Hassas veri (kimlik bilgisi, kart verisi) olaya yazılırken özel dikkat gerekir. Olaylar çoğu zaman uzun süre saklanır ve çok sayıda tüketiciye ulaşır; bu veriler maskelenir, ayrı güvenli bir kaynakta tutulup referansla taşınır ya da şifrelenir.

Zarf (envelope) ve ortak metadata

İş verisinin dışında her olayın tutarlı bir zarf alanı olmalıdır. Bu alanlar yayımlayanı ve tüketiciyi bağımsız olarak çalışır kılar:

• Olay kimliği: tekrar işlenmeyi (idempotency) tespit etmek için benzersiz tanımlayıcı.
• Olay türü ve şema sürümü: tüketici hangi biçimle karşılaştığını bilir.
• Oluşma zamanı: olayın iş dünyasında gerçekleştiği an; yayımlanma zamanından ayrı tutulur.
• Kaynak servis ve ilişki kimliği (correlation id): olayı bir iş akışı boyunca izlemeye yarar.
• Sıra bilgisi: aynı varlığın olaylarını doğru sırada işlemek için gereken anahtar ya da sürüm.

Zarfın standartlaştırılması, tüm olaylarda aynı izleme, hata ayıklama ve yeniden işleme araçlarının kullanılmasını sağlar. Her ekip kendi zarfını icat ederse, platform düzeyinde araç yazmak imkânsızlaşır.

Şema yönetimi: nasıl tanımlanır, nasıl kayıt altına alınır?

Olay şeması, alanları, türlerini ve zorunlu olup olmadıklarını tanımlayan biçimsel bir belgedir. Şema tanım dilleri (örneğin Avro, Protobuf, JSON Schema) bu amaçla kullanılır; hangisinin seçileceği ekosistemin ve araçların desteğine bağlıdır. Önemli olan, şemanın kodun içinde dağınık biçimde değil, merkezi ve sürümlü bir yerde tutulmasıdır.

Birçok ekip şema kayıt servisi (schema registry) kullanır. Yayımlayan, yeni bir şema sürümü kaydetmek istediğinde sistem bunu mevcut sürümlerle karşılaştırır ve uyumluluk kuralını ihlal ediyorsa kaydı reddeder. Böylece uyumsuz değişiklik üretime çıkmadan engellenir.

Şemayı kod olarak yönetmek, değişikliklerin gözden geçirme sürecinden geçmesini sağlar: şema değişikliği bir pull request'tir, etkilenen tüketiciler incelemede görünür olur.

Şema evrimi: geriye ve ileriye uyumluluk

Şema değiştiğinde uyumluluk sorusu çift yönlü olarak gündeme gelir:

• Geriye uyumluluk: yeni şemayla yazılmış olay, eski şemayı bekleyen tüketici tarafından hâlâ okunabilir mi? Ya da yeni tüketici eski olayları okuyabilir mi? Hangisinin kastedildiği açıkça tanımlanmalıdır.
• İleriye uyumluluk: eski şemayla yazılmış olayları yeni şemayı bekleyen tüketici işleyebilir mi?

Uyumluluğu koruyan değişiklikler genellikle şunlardır: isteğe bağlı alan eklemek (varsayılan değerle), yeni olay türü eklemek, mevcut alanın açıklamasını netleştirmek. Uyumluluğu bozan değişiklikler: alan silmek ya da yeniden adlandırmak, alan türünü değiştirmek, zorunlu alan eklemek, mevcut alanın anlamını farklılaştırmak.

Uyumsuz değişiklik kaçınılmazsa şu yollar izlenir: • Yeni sürüm olayı ayrı bir tür olarak yayımlamak (örneğin sürüm eki taşıyan yeni bir ad); yayımlayan geçiş dönemi boyunca eski ve yeni olayı birlikte yayımlar, tüketiciler taşınır, eski sürüm emekliye ayrılır. • Tüketici tarafında dönüştürücü (upcaster) kullanmak: eski olay okunurken yeni biçime çevrilir. • Veriyi yeni bir konuya ya da kanala taşıyarak eski ve yeni dünyaları ayırmak.

Her durumda kaldırılan ya da değiştirilen alan için bir kullanımdan kaldırma duyurusu ve tüketicilerin taşınması için takvim gerekir.

Sık yapılan hatalar ve test

Olay tasarımında sık görülen hatalar şunlardır: • Olayı veritabanı değişiklik kaydı gibi tasarlamak, iş anlamını kaybetmek. • Yayımlayan ekibin iç modelini olay şemasına yansıtmak; iç refaktör tüm tüketicileri kırar. • Şemayı kayıt altına almadan yayımlamak ve uyumluluğu yalnızca üretimde keşfetmek. • Aynı olaya farklı anlamlar yüklemek, zamanla alan anlamını kaydırmak. • Tüketicinin bilmediği alanlara tolerans göstermemek: tüketici bilinmeyen alanı yok sayabiliyorsa (toleranslı okuyucu), yeni alan eklemek tüketicileri bozmaz.

Test için sözleşme testleri (consumer-driven contract testing) kullanılır: tüketici beklediği şemayı tanımlar, yayımlayan her değişiklikte bu beklentilerin korunduğunu kanıtlar. Ayrıca eski olay örnekleriyle yeni tüketici kodu, yeni olay örnekleriyle eski tüketici kodu çalıştırılarak uyumluluk doğrulanır. Bu testler sürekli entegrasyon hattının bir parçası olmalıdır.

Bu beceriyi Mindset programlarında nerede çalışırsınız?

Event-Driven Mimari eğitiminin modül başlıkları arasında Olay Tasarımı ve Şema, Olay Güdümlü Mimariye Giriş, Üretici Tasarım Desenleri, Tüketici Tasarım Desenleri, Mesaj Aracısı Seçimi ve Yapılandırma ile EDA Test Etme ve İşletme yer alır. Olay ve şema tasarımı konusu doğrudan Olay Tasarımı ve Şema modülüyle örtüşür; üretici-tüketici desenleri ve test başlıkları ise sözleşme yönetimini tamamlar.

Backend geliştiriciler, yazılım mimarları ve platform mühendisleri için uygundur. Kurumsal ekipler kendi alanlarından bir olay kataloğunu çalışma örneği olarak getirip adlandırma ve uyumluluk kurallarını uygulayabilir.