Event Driven (Olay Odakli) vs Event Sourced (Olay Kaynakli)

Günümüzde microservice mimarisinin yaygın kullanımı ile popülaritesi artan bir diğer konu da mesaj tabanlı iletişim mekanizmalarıdır. Servisler arasında haberleşmeyi sağlayan mesajlar çoğunlukla event (olay) bilgilerini taşırlar. Karışıklığın başlangıcı da burada gerçekleşiyor. Yazilimcilar, kendi aralarindaki konuşmalar sirasinda bolca Event terimi duyuldukça, bu kavrama yeni olan kişiler tarafından gerçekleştirilen tartışmalarda sıklıkla ortaya çıkan bir karışıklık vardır. Event Driven (olay odaklı) ve Event Sourced (olay kaynaklı) Terimleri genellikle birbirinin yerine kullanılmaktadır. Aslında bu iki terim birbirinden çok farklı kavramları ifade etmektedir. Bu makalede aklınızda oluşan bu karmaşıklığı giderecek bilgiler vermeye çalışacağım.

Konuya derinlemesine bir dalış yapmadan once “Event” tanımını hem Event Driven hem de Event Sourced sistemler için netleştirelim. Event, geçmişte meydana gelmiş bir şeyi tanımlayan değişmez bir kayıttır. Bu nedenle bir event’in içerdiği veririler değiştirilemez. Değişmezlik ve geçmişin tanımı event’lerin en temel özelliklerindendir.

Event Driven (Olay Odaklı)

Event Driven, esasen daha büyük bir sistemin çeşitli bileşenleri veya sistemler arasında bir iletişim mekanizması olarak olayları kullanan bir mimari tarzdır. Event’lar, gönder ve unut yönteminde asenkron olarak işlenir; yani publisher, consumer’lardan bir yanıt beklemez. Olayı abone olan sistemin diğer parçaları işler ve daha fazla olaydan oluşan daha büyük iş akışlarını tetikleyebilir. Örneğin, microservice tabanlı bir sistem, bir microserviste bir olayın meydana geldiğini iletmek için event’lari kullanabilir. Bu event’lar, diğer mikro hizmetlerdeki consumerlar tarafından işlenebilir ve bu consumerlar da değişikliklerini iletmek için kendi event’lerini yayabilir.

• Event’lar, aynı event’ı aynı anda birden fazla consumer’in işlemesine olanak tanıyan bir pub-sub yöntemiyle yayınlanır.
• Her consumer, event’in kendi kopyasını alır.
• Event Driven Architecture’ın asenkron doğası genellikle nihai tutarlılığa yol açabilir. Bu, sistemin durumunun bileşenler arasında anında yansıtılmayabileceği anlamına gelir.
• Event Driven sistemler genellikle, ama her zaman değil, Publisher’dan consumer’a event’lari iletmek için bir mesaj aracısı kullanır.
• Bileşenler genellikle iki tür olayı kullanır: domain ve integration. Domain Event’lari, yayıcı bileşenlerin içindedir, integration event’lari ise bileşenler arasında iletişim için kullanılır.
• Belirli bir sistemdeki çoğu, hatta tüm bileşenler tarafından tipik olarak kullanılır; her biri bir event alt kümesine yayın yapar ve bunlara abone olur.

Event Sourced (Olay Kaynakli)

Event Driven (Olay Odakli) vs Event Sourced (Olay Kaynakli)

Event Driven Architecture’in, iletişim için olayları kullanan bir mimari tarz olmasının aksine, Event Sourced bir kalıcılık mekanizmasıdır. Event’lar, bir varlığın durumundaki değişiklikleri yansıtmak ve o durumu yeniden oluşturmak için kullanılır. Bir domain işlemi tamamlandığında, belirli bir varlıkla bağlantılı bir akış olarak bir dizi olay saklanır. Örneğin, bir alışveriş sepetinde gerçekleştirilen bir dizi eylem aşağıdaki event’lara yol açabilir:

• Alışveriş başladı
• Öğe eklendi
• Öğe eklendi
• Öğe çıkarıldı
• Öğe eklendi

Sepetin durumunu yeniden oluşturduğunda, bu olaylar kronolojik sırayla yüklenir ve durumu birer birer güncellemek için tekrar oynatılır. Ortaya çıkan sepet iki öğe içerecektir.

Olay kaynağı aşağıdaki anahtar özelliklerle tanımlanabilir:

• Bir işlemi tamamladıktan sonra, varlık değişikliklerin doğasını yansıtan yeni Event(lar) içerir ve bunlar daha sonra bir Event Store’a kaydedilir.
• Event’lar kesinlikle belirli bir varlıkla bağlantılıdır.
• Tipik olarak, olaylar kapsamı sınırlı, güçlü ve tutarlı bir şekilde katılır. Başka bir süreç aynı anda akışa olay eklerse kalıcı olmayacaktır.
• Yeni event’lar, ya hepsi ya da hiçbiri kaydedilerek işlem bazında kalıcı hale getirilir.
• Event’lar, varlığın durumunu yeniden oluşturmak için akıştan yüklenir.
• Tek bir bileşenle sınırlıdır. Daha büyük bir sistem, yalnızca bir alt kümenin ES kullandığı heterojen kalıcılık mekanizmaları içerebilir.

 

Farklı Ama Tamamlayıcı

Event Driven ve Event Sourced’in özelliklerini karşılaştırdığımızda, ikisinin çok farklı olduğu açıkça ortaya çıkıyor. Gerçekten de, yazılım tasarımının temelde farklı yönlerini ele alıyorlar. Event Driven, iletişim için bir mimari stilken, Event Sourced, varlıkların durumunu koruma mekanizmasıdır. Ancak, bu farklılıklar iki yaklaşımın birbirini dışladığı anlamına gelmez. Aksine, Event Driven ve Event Sourced genellikle birbirini tamamlayarak el ele gider.

Böyle bir yapılandırmada, Event Sourced kullanan bir bileşen iş mantığını işler ve varlığının durumunu event kaynaklı bir şekilde depolar. Bir noktada, Event Driven’a katılan diğer bileşenlerin ilgisini çekebilecek bir eylemin tamamlandığını belirten bir event yayınlanacaktır. Bu, yalnızca belirli bir event veya başka yerlerde işlenmesi gereken birden fazla event’dan veri toplama olabilir. Her iki durumda da, bir publusher bu event(lar)ı bir integration event’ina eşleştirir ve yayınlar, böylece diğer bileşenlerde tüketilmesine olanak tanır.

Event Driven ve Event Sourced’in belirgin doğası aynı zamanda onların gücüdür — her yaklaşım farklı bir alana odaklanır, ancak birlikte daha geniş bir sisteme katkıda bulunurlar, bir bileşendeki değişikliklerin denetim izini ve ince detayını sağlarken, Event Driven Architecture’i diğer bileşenlere seçilen değişiklikleri iletmek için kullanırlar.