Event Driven Architecture - Başlangıç

Giriş

Yazılım sistemleri büyüdükçe, başka yazılım sistemlerine olan bağımlılıkları da artar. Bu bağımlılıklar, geliştirici ekiplerin büyümesiyle birlikte yönetilmesi zor, büyük kod yığınlarına dönüşebilir. Her yeni kod dağıtım sürecinde ekipler, "Acaba yeni bir özellik eklerken neyi bozduk?" endişesine kapılabilir. İşte bu noktada, büyüyen veya hâlihazırda büyük olan projelerde sistemlerin ve servislerin birbirleriyle iletişim kurmasını sağlayan Event-Driven Architecture (EDA) devreye girer.

Event (Olay) Nedir?

Bu yaklaşımda event (olay), sistemde geçmişte gerçekleşmiş ve değiştirilemez bir durumu ifade eder. Daha açık bir ifadeyle, iş süreçlerinde meydana gelen olaylardır. Örneğin, bir siparişin oluşturulması veya bir ödemenin alınması gibi durumlar birer event olarak değerlendirilir.

Event-Driven Mimari (EDA) Nedir?

Event-Driven Mimari, iş olaylarının (event) sistemdeki bileşenleri asenkron olarak tetiklemesini sağlayan bir iletişim modelidir. Bileşenler birbirleriyle doğrudan bağlı olmak yerine olaylar aracılığıyla haberleşir.

EDA, kullanıcı deneyimlerini teknik süreçlere entegre etmeyi kolaylaştırır. Örneğin, bir e-ticaret sisteminde kullanıcı bir ürünü satın almak istediğinde çeşitli adımları tamamladıktan sonra bir sipariş oluşturulur. "Order Created" (Sipariş Oluşturuldu) Event’i, sistemde yapılması gereken diğer işlemleri tetikler. Bu event'i dinleyen farklı servisler devreye girer:

• Teslimat servisi ürünü hazırlar.
• Ödeme servisi ödemeyi işler.
• Stok yönetim servisi envanteri günceller.

EDA’nın çözmeye çalıştığı temel problem, bağımlılıklardır (coupling). Eğer sistemler tamamen bizim kontrolümüzdeyse bağımlılıkları yönetmek kolay olabilir. Ancak dış sistemlerle entegrasyon söz konusu olduğunda, bu bağımlılıklar ciddi sorunlara yol açabilir. Amacımız düşük bağımlılık ve yüksek uyumluluk sağlamaktır. Böylece sistemin gelişimi ve bakımı daha kolay olur.

Event ve Mesaj (Message) Arasındaki Fark

Aslında event, bir mesaj türüdür. Mesajlar, iletişimin temel yapı taşıdır. Yazılım sistemleri de bu kavramı kullanarak bileşenler arasında iletişim sağlar. Peki kaç tür mesaj vardır?

Mesaj Türleri:

1. Commands (Komutlar): Bir sistemin belirli bir işlemi gerçekleştirmesini talep eder.
2. Events (Olaylar): Geçmişte gerçekleşmiş bir durumu bildirir. Bizim konumuz olan evenlerdir. 
3. Queries (Sorgular): Sistemde belirli bir veri hakkında bilgi almak için kullanılır.

Örneğin, bir e-ticaret sisteminde şu akış gerçekleşebilir:

• Query: Kullanıcı, ürün listesini sorgular.
• Command: Kullanıcı bir ürünü satın almak için sipariş oluşturur.
• Event: Sipariş oluşturulduğunda, diğer servisleri bilgilendiren bir event yayımlanır.

Event-Driven Mimari ve Mikroservis Mimarisi

EDA, mikroservis (microservices) veya monolitik (monolith) mimariyle doğrudan ilişkili değildir. Çünkü EDA bir iletişim modelidir.

Bir sistem ister monolitik ister mikroservis tabanlı olsun, bileşenler arasında iletişim gerektiğinde EDA avantaj sağlar. Mikroservis veya monolitik yaklaşım ise kod organizasyonu ve iş mantığıyla ilgilidir.

Event Storming

EDA'yı anladıktan sonra şu sorabiliriz: Sistemimdeki event'leri nasıl belirleyebilirim? Cevap:

📌 Event Storming, bu süreci yönetmek için kullanılan bir tekniktir.

Event Storming ile Neler Yapılabilir?

Bu teknik, büyüyen iş alanlarında event-driven sistemleri tasarlamak ve yönetmek için kullanılır.

Temel fikir:

• Tüm paydaşları, domain uzmanlarını ve geliştiricileri bir araya getirmek
• Sistemde gerçekleşen event'leri belirlemek
• Teknik detaylardan bağımsız bir şekilde yalnızca iş süreçlerine odaklanmak

Nasıl Uygulanır?

1. Katılımcılar, sistemde gerçekleşen event'leri yazar ve bir duvara yapıştırır.
2. Farklı isimlerle yazılmış event'ler, ortak bir dil (ubiquitous language) oluşturmak için gözden geçirilir.
3. Event'ler, oluş sırasına göre sıralanır.
4. Event’lere neden olan Command (Komut) ve Query (Sorgu) gibi mesajlar eklenir.

Event-Driven Sistemlerin Temel Bileşenleri

EDA sistemleri şu temel bileşenlerden oluşur:

1. Producer (Üretici): Event’i oluşturan ve yayımlayan bileşen.
2. Consumer (Tüketici): Event’i dinleyen ve işleyen bileşen.
3. Message Transport Layer (Mesaj Taşıma Katmanı): Event’lerin taşınmasını sağlayan iletişim kanalı.

İletişim şu iki yöntemle sağlanabilir:

Point-to-Point (P2P) Mesaj Kanalları

• Bir servis, doğrudan başka bir servis ile iletişim kurar.
• Örneğin, Sipariş Servisi doğrudan Ödeme Servisi ile iletişime geçer.
• Dezavantajı: Başka servisler aynı kanalı kullanamaz, bağımsız ölçeklenme zor olabilir.

Publish/Subscribe (Pub/Sub) Mesaj Kanalları

• Bir event, birden fazla servis tarafından dinlenebilir.
• Örneğin, "Sipariş Oluşturuldu" event’i hem Ödeme Servisi, hem Teslimat Servisi tarafından işlenebilir.
• Daha esnek ve ölçeklenebilir bir mimari sunar.

Queue, Bus/Topic ve Stream Farkları

• Queue: Kuyruk mantığında çalışır, tüketici offline olsa bile event’leri tutar.
• Bus/Topic: Event’leri yayar ancak kalıcı depolama sağlamaz.
• Stream: Event’leri sırayla işler, tüketicinin en son aldığı event’i takip eder.

Event-Driven Mimarinin Avantajları ve Dezavantajları

✅ Avantajlar:

• Ölçeklenebilir ve esnektir.
• Asenkron iletişim sağlar.
• İş süreçlerini teknik sistemlere daha iyi yansıtır.

❌ Dezavantajlar:

• Servisler arasındaki ilişkileri takip etmek zor olabilir.
• Yanlış tasarlanmış bir EDA, yönetilmesi güç bir yapıya dönüşebilir.

Sonuç

Başlangıçta basit görünen iletişim süreçleri, sistem büyüdükçe karmaşıklaşır ve farklı yazılımlar ile entegrasyon ihtiyacı doğar. Event-Driven Mimari, bu süreci yönetmek için güçlü bir yaklaşımdır. Ancak, başarılı bir uygulama için temel prensipleri ve ilgili teknolojileri iyi anlamak gerekir.