Event Sourcing Nedir ve Nasıl Çalışır?
Uygulamanızın günlük tutma yöntemi
You can access the English version via this link.
Event-Sourcing ve CQRS birbirinden farklı yazılım geliştirme desenleridir. Birlikte kullanılmaları gibi bir zorunluluk yoktur. Bu sebeple; iki deseni birlikte değil ayrı ayrı inceleyeceğiz. Ardından da bu iki desenin neden sık sık bir arada anıldıklarından bahsedeceğiz.
Not: CQRS üzerine olan yazıya bu link üzerinden erişebilirsiniz. Event Sourcing ve CQRS desenlerinin neden birlikte sık sık anıldığını açıkladığımız bölüme gelmeden önce okumanızı tavsiye ederim.
Event Sourcing
Öncelikli olarak yazılım sektöründe ve bu yazıda Event kelimesinin bizim için ne anlama geldiği ile başlayabiliriz. Event, bir istek üzerine sistemde belli başlı aksiyonların yürütülmesi sonucu ortaya çıkan durumdur. Kısaca; bir olayın gerçekleşmesi durumu da denebilir. Örneğin; bir kullanıcının sistem üzerinde hesap açma isteğinin yazılım tarafından yerine getirilmesi sonucu ortaya çıkan duruma “KullanıcıOluşturuldu” diyebiliriz.
Not: Event, sistem üzerinde olmuş bir olaya denir. Bu sebeple geçmiş zaman eki ile biter.
Event Sourcing Nedir?
Event Sourcing, yukarıda bahsi geçen Event bilgilerinin (sistemimizde gerçekleşmiş olayların) biriktirilmesi ana fikri üzerinde biçimlenen bir yöntemdir.
Event Sourcing Nasıl Çalışır?
Yazılım dünyasında bir kimliğe sahip olan, sistemin ana parçalarından olan objelere varlık denir.
Geleneksel yazılım geliştirme yönteminde bir varlık üretilir ve sonrasında veri saklama ortamında saklanır. Ardından çeşitli etmenler sebebiyle bu varlığın durumunda bir değişiklik yapılması gerekirse, değişiklikler doğrudan varlığın veri saklama ortamındaki kopyası üzerinde yürütülür. Yani her bir istek yürütüldükten sonra varlığın son hali veri saklama ortamımızda saklanır.
Event Sourcing ile geliştirilen sistemlerde ise varlıkların son durumları kaydedilmez. Bunun yerine varlıkların durumlarını etkileyen olaylar kaydedilir. İstemci tarafından sorgu gönderilip varlığın son durumu talep edilince, sistem elinde var olan Event bilgilerini birleştirerek istemciye gereken bilgiyi sunar.
Bu işlemi örnekleyerek açıklayalım. Geliştirdiğimiz bir sistemde kullanıcıyı temsil eden bir varlığın yer aldığını düşünelim. Kullanıcının; Ad, Soyad, EPosta, EPostaOnaylandı, Şifre gibi bilgilere sahip olduğunu düşünelim. Sırası ile aşağıdaki aksiyonları yerine getirdiğini farz edelim.
- Kullanıcı e-posta ve şifre bilgisi ile hesap açtı
- Kullanıcı adını ve soyadını güncelledi
- Kullanıcı e-posta hesabını onayladı
Geleneksel sistem ile kullanıcı verilerini sakladığımız zaman, veri saklama ortamımızın içeriği aşağıdaki gibi olabilir.
T1
T2
T3
Event Sourcing yapısında ise aynı aksiyonların yürütülmesi durumunda oluşabilecek örnek içerik aşağıdaki gibi olabilir.
T1
T2
T3
Event Sourcing yöntemi ile kullanıcı varlığının herhangi bir zamandaki durumunu oluşturmak artık mümkün bir haldedir. Bunun için dilediğimiz zamandan öncesinde gerçekleşmiş tüm Event bilgilerini elde etmemiz gerekmektedir. Ardından oluşmuş durumlara ait verileri, boş bir kullanıcı nesnesi üzerinde, oluşma tarihine göre sırasıyla yürütürüz. Sonunda elde etmiş olduğumuz kullanıcı nesnesi talep ettiğimiz zamanda kullanıcı varlığının durumunu bize söylüyor olacaktır.
Event Sourcing vs Geleneksel Yazılım Geliştirme Tekniği
Yukarıdaki örnekte görüleceği gibi; geleneksel yazılım geliştirme yönteminde, sürekli varlığımızın en son halini saklamaktayız. Böyle bir sistemde kullanıcının herhangi bir zamandaki durumuna geri dönmemiz mümkün olmayacaktır. Event Sourcing yönteminde ise sistemin durumunu istediğimiz bir zaman dilimi için oluşturabiliriz.
Geleneksel yazılım geliştirme yönteminden farklı olarak, Event Sourcing yönteminde sistem üzerinde olaylar oldukça veri depomuza yeni kayıtlar eklenir. Olmuş bir olay değişmez veya geri alınamaz olduğu için güncelleme ve silme işlemleri bulunmaz.
Buna karşın veri okuma noktasında, performans kıyaslaması yapıldığı zaman geleneksel yöntem Event Sourcing yönteminden daha hızlı sonuç vermektedir. Event Sourcing yapısında, istemci veriyi talep ettiği zaman varlıkla ilgili olayların dökümü elde edilir. Bu dökümden verinin durumu oluşturulur. Veriden durum oluşturma sürecinin, verinin hazır olarak tutulduğu geleneksel yönteme kıyasla daha yavaş sonuç vereceği aşikardır.
Geleneksel yöntemde kolay olan bir diğer işlem ise ad, soyad gibi alanlar üzerinde sorgulama yapmaktır. Buna karşın Event Sourcing yönteminde ise kullanıcılarınızı ilişki anahtarı diye adlandırdığımız değerden başka bir veri ile sorgulamanız mümkün değildir.
Event Sourcing yöntemi kullanılması durumunda ortaya çıkan son iki sorunu (varlığın her seferinde yeninden oluşturulması ve varlığın alanlarına göre filtrelenmesi) CQRS ile birlikte çözebilmekteyiz. Bu sebeple Event Sourcing ve CQRS sık sık bir arada bahsedilmektedir.
Event Sourcing ve CQRS
CQRS deseni üzerinde okuma ve yazma modellerinin var olduğunu anımsayacaksınızdır. Event Sourcing yönteminde ise varlığın değil varlığın durumunu etkileyen Event bilgilerinin saklandığını söylemiştik. Şimdi bu iki bilgiyi birleştirelim.
Event bilgilerini yazma modeli olarak ve varlığımızın son durumunu okuma modeli olarak düşünelim. İstemci, sistem üzerinde varlığın durumunu değiştirmek için bir operasyon başlatsın. Operasyon sonucu oluşan Event bilgisini yazma modeli olarak sistemimizde saklayalım. Bu durumda yazma modelimize bağlı olarak sürecimiz tetiklensin ve okuma modelimizi de güncelleyelim. Sonuç olarak sistemimizde yazma modeli sayesinde Event Sourcing yapısına sahip olduk. Sistemimizin istediğimiz bir zamandaki durumuna erişmemiz mümkün. Bir yandan da sorgulama işlemleri ve performans sorunu için okuma modelini kullanarak sorunumuzu çözmüş oluyoruz.
Yukarıdaki sistem her ne kadar kulağa hoş geliyor olsa da, önemli bir gerekçeden dolayı her yerde kullanılmamaktadır. Bu tipte bir sistem kurmak, geleneksel yapılı bir yazılıma göre daha komplekstir. Bu karmaşıklık sebebiyle bakım ve sürdürme maliyeti de oldukça yüksektir.
