Olay Kaynak Üretme Temel Kavramları
[[academy-video-youtube({"vid": "HKspPiCGE2E", "start_time": "0", "title": "Event Sourcing Core Concepts", "creator": "Derek Comartin", "length": "11m 31s"})]]
Olay kaynağı, özellikle C# ve .NET Core uygulamaları ile modern yazılım mimarisinde sıklıkla kullanılan güçlü fakat karmaşık bir kalıptır. Olay kaynağını nasıl uygulayacağınızı tam olarak kavrayabilmek için, CodeOpinion.com'dan Derek Comartin'in 'Event Sourcing Core Concepts' videosunda açıkladığı ana prensiplerden geçeceğiz.
Olay mağazası kavramlarını, alan odaklı tasarımı veya olay kaynaklı sistemleri nasıl oluşturacağınızı daha iyi anlamak istiyorsanız, doğru yerdesiniz. Haydi dalalım!
Event Sourcing'e Giriş
Başlangıçta (0:00), Derek, olay kaynağı ve buna bağlı ana konseptler etrafındaki kafa karışıklığını tartışır. Olay kaynağını sadece 'mevcut durumu yakalamak' değil, olayları saklamak — etki alanı modelinize yapılan her değişikliği eklemeli bir logda yakalamak olarak tanımlar.
Bu şekilde, sisteminizin durum değişikliklerinin tam tarihçesini korursunuz. Sadece son durumu sürekli tutmak yerine, gerçekleşen iş mantığını yansıtan olayları sürekli tutarsınız.
Olaylar: İşletme Gerçeklerini Yakalama
0:33'de, Derek, bir olayın gerçek anlamını açıklar. Bir olay, sistemde zaten gerçekleşmiş bir şeyi — bir iş gerçeğini temsil eder. Örneğin, bir 'ÜrünAlındı' olayı, alınan miktarı ve tarihi içerirdi.
Derek, olayları sakladığınızda, bunların geçmiş zamanı yansıtan bir adlandırma kuralı kullanılarak adlandırılması gerektiğini vurgular, örneğin 'Ürün Gönderildi' veya 'Envanter Ayarlandı'. Bir olay şemasında, public Guid Id, public string Name ve zaman damgaları gibi alanlara sahip olabilirsiniz.

Her olay, olayları olay akışına eklediğiniz eklemeli bir depolama sistemi için benzersiz bir kimliğe sahip olmalıdır.
Olay Akışları: Olayları Düzenleme
2:02'de, Derek olay akışlarına geçiş yapar. Bir ilişkisel veritabanı tablosu ile bir kıyaslama yapar, ancak olay kaynaklamada, etki alanı nesnesi ile ilgili tüm olayların (örneğin bir envanter öğesi) aynı olay akışına ait olduğunu açıklar.
Her olay akışı belirli bir varlığa bağlıdır — genellikle public Guid Id ve string Name ile tanımlanır. Örneğin, SKU ABC123 olan bir ürün, alım veya gönderim gibi kalıcı olayları içeren kendi akışına sahip olurdu.
Derek, bunları modellerken, alan odaklı tasarım kavramlarından benzer şekilde, agregat kökler ve etki alanı nesneleri olarak düşünmenizi önerir.
Yaşam döngüsünü modelleme — ister kısa ömürlü ister uzun ömürlü — akışların sayı ve boyutunu optimize etmeye yardımcı olur. Bu, karmaşık sistemlerde performansı artırmak için çok önemlidir.
Projeksiyonlar ve Okuma Modelleri
4:12'de, Derek projeksiyonlar ve okuma modeli kavramını tanıtır. Olay kaynağı sisteminiz mevcut durumu değil olayları yakaladığından, 'Mevcut envanter miktarı nedir?' gibi soruları yanıtlamak için olayları tekrar yürütmeniz gerekir.
Okuma modelleri oluşturmak için, akışı olaylar ile işlersiniz. Örneğin, private void Apply(Event e) veya benzeri kullanarak, her olay türü için olay işleyicilerle stoğu artırır veya azaltırsınız.
Derek, bir doküman veritabanında veya ilişkisel bir veritabanında okuma modeli oluşturmanın nasıl yapılacağını gösterir — belki bir projeksiyon sadece eldeki miktarı gösterir, başka biri gönderim geçmişini gösterir.
Bu, komut sorgusu sorumluluk ayrımı (CQRS) — yazma işlemlerini (komutları) okuma işlemlerinden (sorgulamalar) ayırmayı yansıtır.
Projeksiyonları Yazma Modelleri İçin Kullanma
6:48'de, Derek yazma tarafında projeksiyonların nasıl uygulanacağını da gösterir. Bu, eylemler gerçekleşmeden önce doğrulamak için hayati öneme sahiptir.
Bir komut işleyicisinde, ürünleri göndermeden önce, yeterli miktarın mevcut olduğundan emin olmalısınız. Derek, gerekli durumu yeniden oluşturmak için private void Apply(List<Event> events) gibi bir yöntem kullanır.
Public int Version gibi alanlar, akışın evrimini izlemeye yardımcı olur ve sonunda tutarlılığı sağlar.

Bu pratik uygulama, yeni olaylarla ilgilenirken iş mantığını uygulamaya yardımcı olur, sisteminizin yalnızca geçerli durum geçişlerinde hareket etmesini sağlar.
Abonelikler: Yeni Olaylara Tepki Vermek
Saat 8:01'de, Derek abonelikler hakkında konuşuyor. Abonelikler, olay tüketicilerinin yeni olaylar için dinleyip onlara tepki vermesine olanak tanır.
Örneğin, bir projeksiyon cihazı, bir olay akışına abone olabilir ve 'Ürün Sevk edildi' olayını gördüğünde bir okuma modelini güncelleyebilir. Alternatif olarak, bir yayıncı, olayları dinleyip, onları RabbitMQ veya Kafka gibi dış sistemlere yayınladığında, diğer hizmetlerle entegre olabilir.

Derek, aboneliklerin yalnızca dahili modelleri güncellemek için değil, aynı zamanda ayrı olay sistemleri arasında veri dağıtımı için kullanıldığını ve nihai tutarlılığı koruduğunu açıklar.
Bu, olay yönelimli mimarinin bir diğer önemli faydasını gösterir: hizmetleriniz bağımsız olarak ölçeklenebilirken nihayetinde tutarlı kalır.
Çekirdek Kavramların Tekrarı
Saat 9:21'de, Derek temel kavramları özetler:
Olaylar gerçekleri yakalar.
Olay Akışları, olayları varlık bazında düzenler.
Projeksiyonlar, akışları sorgulanabilir okuma modellerine veya eyleme geçirilebilir yazma modellerine dönüştürür.
- Abonelikler, hizmetlerin tepki vermesine ve buna göre güncellemesine olanak tanır.
Olayları yalnızca ekleme günlükleri içinde tutmanın, bir denetim izi sağlamanın ve gerektiğinde olayları tekrar oynatma yeteneğinizin önemli olduğunu vurgular.
Anlık Görüntüler ve Optimizasyon
Saat 9:39'da, Derek anlık görüntü oluşturmayı ele alır. Genellikle olay kaynağıyla birlikte tartışılmasına rağmen, anlık görüntülerin bir performans optimizasyonu olduğunu, temel bir gereklilik olmadığını açıklar.
Anlık görüntüler tüm olayları yeniden oynatma yükünü azaltır; ancak, tam geçmiş eklemeli günlüğü aracılığıyla hala mevcuttur.
Anahtar Ayırımı: Olay Kaynağı vs Olay Yönelimli Mimari
Saat 10:00'da, Derek yaygın bir yanlış anlama konusunda uyarır: olay kaynağı ve olay yönelimli mimari farklıdır! Kafka gibi araçlar veri dağıtımı konusunda yardımcı olur, ancak gerçek olay kaynağı, alan olaylarını değişmez bir denetim izi olarak kaydetmeye odaklanır.
Olay kaynağını karmaşık sistemlerinize entegre ederken ayrımı anlamak çok önemlidir.
Sonuç
Derek Comartin'in videosunu takip ederek, olay kaynağının her değişikliği bir olay olarak kaydetmekle ilgili olduğu, sadece nihai haliyle ilgili olmadığı netleşiyor. Olayları yalnızca ekleme depolama sistemi içinde tutarak, bir denetim izi sağlayan, olayları sorgulamak için esneklik sunan ve komut sorgusu sorumluluk ayrımını güçlü bir şekilde destekleyen zengin bir olay şeması oluşturursunuz.
C# olay kaynağı ile .NET Core veya başka herhangi bir platformla ilgileniyorsanız, Derek'in temel kavramlarının, olay yöneticilerinin, özel setlerin, korumalı setlerin ve modellerinizde özel void Apply() gibi olayları uygulamanın yapılandırılmış açıklaması son derece değerlidir.
Dayanıklı bir alan modeli oluşturma, depolama sisteminizi iyileştirme veya birkaç fayda sağlayan karmaşık örüntüler oluşturma üzerinde çalışıyorsanız, Derek'in yaklaşımını incelemek bir zorunluluktur. Daha içgörülü videolar için YouTube kanalına göz atın.

