Event Sourcing
- Okunuşu
- ivent sorsing
Kısaca
Event sourcing, uygulama durumundaki her değişikliği değiştirilemez bir olay olarak saklayıp güncel durumu olayları yeniden oynatarak kuran tasarım desenidir.
Event sourcing nedir?
Event sourcing, yalnızca nihai sonucu değil, olanı saklayan bir mimari desendir. Sistem, güncel bakiyeyi tutmak için bir satırı güncellemek yerine, olay deposu (event store) adlı yalnızca ekleme yapılan bir günlüğe AccountOpened, MoneyDeposited ve MoneyWithdrawn gibi olaylar ekler. Güncel durum, bu olaylar sırayla yeniden oynatılarak hesaplanır.
Olaylar değiştirilemezdir (immutable): bir kez yazıldıklarında asla düzenlenmez ya da silinmez; hatalar yeni bir düzeltici olay eklenerek giderilir. Her okumada binlerce olayı yeniden oynatmak yavaş olacağından sistemler durumun anlık görüntülerini (snapshot) belirli aralıklarla kaydeder ve yalnızca son anlık görüntüden sonraki olayları oynatır. Ayrıca yeni olayları dinleyerek güncel tutulan, sorgular için optimize edilmiş tablolar olan okuma modellerini, yani projeksiyonları da oluştururlar.
Banka ekstresi iyi bir benzetmedir: bakiyeniz körü körüne güvenmeniz gereken tek bir sayı değil, ekstrede listelenen her para yatırma ve çekmenin toplamıdır. Event sourcing; finans, muhasebe, sipariş işleme ve tam bir denetim izi gerektiren, geçen salı bunun nasıl göründüğü sorusunu yanıtlayabilmek isteyen ya da verileri daha sonra yeni şekillerde yeniden oluşturma seçeneği isteyen her alanda popülerdir.
Event sourcing sıklıkla olay güdümlü mimariyle karıştırılır. Olay güdümlü mimari servislerin olay yayınlayıp bunlara tepki vererek iletişim kurmasıyla ilgilidir; event sourcing ise olayların bir servisin kendi verisi için depolama modeli olarak kullanılmasıyla ilgilidir ve biri diğeri olmadan da kullanılabilir. Çoğunlukla, olayları kaydeden yazma tarafını sorguları sunan okuma tarafından ayıran CQRS ile eşleştirilir. Ödünler gerçektir: olay biçimleri dikkatle evrilmelidir ve okuma modelleri çoğunlukla nihai tutarlıdır, yani en son olayların biraz gerisinde kalabilirler.
Bir bakışta
Önemli noktalar
- Durum değişiklikleri, yalnızca ekleme yapılan değiştirilemez bir olay dizisi olarak saklanır.
- Güncel durum, çoğunlukla bir anlık görüntüden başlayarak olaylar yeniden oynatılarak oluşturulur.
- Tam bir denetim izi sağlar ve geçmiş durumları yeniden oluşturmayı mümkün kılar.
- Çoğunlukla CQRS ile birleştirilir ama olay güdümlü mimariyle aynı şey değildir.
- Olay biçimlerinin evrilmesi ve nihai tutarlı okuma modelleri karmaşıklık ekler.
Örnek
type AccountEvent = { type: "MoneyDeposited" | "MoneyWithdrawn"; amount: number };
// The event store only ever appends; past events are never changed
const events: AccountEvent[] = [
{ type: "MoneyDeposited", amount: 100 },
{ type: "MoneyWithdrawn", amount: 30 },
{ type: "MoneyDeposited", amount: 50 },
];
// Rebuild the current balance by replaying every event in order
const balance = events.reduce(
(total, e) => (e.type === "MoneyDeposited" ? total + e.amount : total - e.amount),
0,
);
console.log(balance); // 120Sık sorulan sorular
Event sourcing ile olay güdümlü mimari arasındaki fark nedir?
Event sourcing, bir servisin kendi verisini olay günlüğü olarak saklar; olay güdümlü mimari ise ayrı servislerin iletişim kurması için olayları kullanır. Bir sistem biri olmadan diğerini kullanabilir, ancak çoğunlukla birleştirilirler.
Olay deposu (event store) nedir?
Olay deposu, olayları eklemek ve sırayla geri okumak için tasarlanmış, genellikle bir hesabın tüm olayları gibi varlık başına gruplanmış bir veritabanı ya da günlüktür. Özel bir veritabanı olabileceği gibi yalnızca ekleme yapılacak biçimde kullanılan sıradan bir tablo da olabilir.
Event sourcing ne zaman kullanılmamalı?
Geçmişin iş açısından pek değer taşımadığı basit oluşturma, okuma, güncelleme ve silme uygulamalarında kaçının. Olay sürümleme, yeniden oynatma ve nihai tutarlı okumalar konusunda karmaşıklık ekler; bu ancak denetlenebilirlik ya da geçmiş durumlara ilişkin sorular gerçekten önemliyse karşılığını verir.
İlgili sayfalar
- CQRSYazılım Mimarisi, s. 7CQRS, veriyi değiştiren kodu (komutlar) veriyi okuyan koddan (sorgular) ayırarak iki ayrı modele bölen bir mimari desendir.
- Olay Güdümlü MimariYazılım Mimarisi, s. 29Olay güdümlü mimari, servislerin bir siparişin verilmesi gibi olaylar üreterek ve bunlara tepki vererek iletişim kurduğu bir yazılım tasarım tarzıdır.
- Domain-Driven DesignYazılım Mimarisi, s. 12Domain-driven design, kodu iş alanına yakından modelleyen ve alan uzmanlarıyla aynı dili kullanan bir yazılım geliştirme yaklaşımıdır.
- Mesaj KuyruğuBackend ve API'ler, s. 28Mesaj kuyruğu, bir servisten gelen mesajları bir başkası işlemeye hazır olana kadar saklayan ve sistemin parçalarını eşzamansız çalıştıran bir bileşendir.
- VeritabanıVeritabanları, s. 37Veritabanı, bilgisayarda düzenli biçimde saklanan ve uygulamaların verimlice kaydedip arayıp güncelleyebildiği, bir yazılımla yönetilen veri topluluğudur.
- MikroservislerYazılım Mimarisi, s. 24Mikroservisler, bir uygulamanın ağ üzerinden iletişim kuran, küçük ve bağımsız olarak dağıtılabilen servislere bölündüğü bir mimari tarzdır.
Kaynaklar
Bu sayfada bir hata ya da eksik mi gördünüz?Düzeltme önerin