Bir acente yazılımında aynı anda pek çok şey olur: Bir kullanıcı trafik teklifi başlatır, başka bir kullanıcı kasko poliçesini kaydeder, muhasebe tarafı tahsilatı işler, yönetici paneli de bütün bunları anlık görmek ister. Bu işlerin her biri birbirini doğrudan çağırarak yürütülürse sistem kısa sürede düğüm düğüm olur. Olay tabanlı mimari, bu karmaşayı "ne oldu?" sorusunun etrafında yeniden düzenler. Bu yazıda bir yazılım sağlayıcısı olarak InsureHub tarafında olay tabanlı yaklaşımı nasıl düşündüğümüzü ve acente yazılımı değerlendiren ekiplerin hangi noktalara bakması gerektiğini anlatıyoruz.
Komut ile olay arasındaki fark
Olay tabanlı tasarımın ilk adımı, iki kavramı birbirinden ayırmaktır. Komut, bir şeyin yapılmasını isteyen mesajdır: "Bu araç için trafik teklifi al." Olay ise geçmişte gerçekleşmiş ve artık değiştirilemeyecek bir gerçeği bildirir: "Trafik teklifi alındı." Komut reddedilebilir; olay ise yalnızca kaydedilir ve ilgilenen bileşenlere duyurulur.
Bu ayrım küçük bir isimlendirme detayı gibi görünse de yazılımın davranışını kökten değiştirir. Teklif modülü, raporlama modülünün varlığından haberdar olmak zorunda kalmaz. Yalnızca olayı yayınlar; raporlama, bildirim ve görev modülleri bu olaya kendileri abone olur.
Acente alanında hangi olaylar anlamlıdır?
İyi bir olay modeli, teknik tablolardan değil iş dilinden doğar. Acentecilikte anlamlı olaylar genellikle şöyle sıralanır:
- MüşteriKaydıOluşturuldu ve MüşteriBilgisiGüncellendi
- TrafikSorgusuBaşlatıldı, KaskoSorgusuBaşlatıldı, DaskSorgusuBaşlatıldı
- ŞirketYanıtıAlındı ve ŞirketYanıtıZamanAşımınaUğradı
- PoliçeleştirmeTamamlandı
- TahsilatKaydedildi
- YenilemeTarihiYaklaştı
Dikkat edilirse trafik, kasko ve DASK için ayrı olaylar tanımlanmıştır. Bunun nedeni, bu üç branşın girdi alanlarının, doğrulama kurallarının ve şirket tarafındaki sorgu akışlarının birbirinden farklı olmasıdır. Tek bir "TeklifBaşlatıldı" olayı içinde bu farkları taşımaya çalışmak, abonelerin her seferinde branşı çözümleyip dallanmasına yol açar.
Olayın içinde ne taşınmalı?
Bir olay yükü (payload) iki uç arasında dengelenmelidir. Yalnızca kimlik numarası gönderilirse her abone ayrıca veritabanına gidip veri çekmek zorunda kalır. Bütün nesne gönderilirse kişisel veriler gereksiz yere çoğalır. Pratik bir kural şudur: Olay; kendisini anlamlı kılan alanları, ilgili kayıt kimliklerini, olay zamanını, olayı tetikleyen kullanıcıyı ve bir sürüm numarasını içersin. T.C. kimlik numarası veya açık adres gibi hassas veriler, gerçekten gerekmedikçe olay yüküne konmasın.
Olay tabanlı yapının acenteye somut katkısı
Mimari tercihlerin değeri, sonunda kullanıcının ekranında hissedilir. Olay tabanlı bir altyapı acente ekibine şunları sağlar:
- Yan etkilerin birbirini bekletmemesi: Poliçe kaydedildiğinde bildirim gönderimi, rapor güncellemesi ve görev oluşturma arka planda ilerler. Kullanıcı, bu işlerin bitmesini beklemeden bir sonraki müşteriye geçebilir.
- Yeni özelliklerin mevcut akışı bozmadan eklenmesi: Örneğin yenileme yaklaştığında mobil bildirim göndermek istendiğinde, yalnızca yeni bir abone eklenir; poliçe modülüne dokunulmaz.
- Geriye dönük izlenebilirlik: Olaylar zaman sırasıyla saklandığında bir teklifin hangi adımlardan geçtiği sonradan okunabilir. Bu, destek taleplerinde tahmin yerine kayda dayalı cevap vermeyi mümkün kılar.
Sık yapılan modelleme hataları
Olayları veritabanı işlemleriyle karıştırmak
"PoliçeTablosunaSatırEklendi" gibi olaylar teknik bir ayrıntıyı dışarı sızdırır. Yarın tablo yapısı değiştiğinde bütün aboneler etkilenir. Olay adı iş dilinde kalmalıdır.
Her şeyi olaya çevirmek
Kullanıcının bir listeyi filtrelemesi veya ekranda sekme değiştirmesi iş olayı değildir. Gereksiz olaylar hem altyapıyı yorar hem de gerçekten önemli sinyalleri görünmez hale getirir.
Sıralamayı varsaymak
Dağıtık sistemlerde olayların yayınlandığı sırayla ulaşacağının garantisi her zaman yoktur. "TahsilatKaydedildi" olayı, "PoliçeleştirmeTamamlandı" olayından önce gelebilir. Aboneler bu durumu tolere edecek şekilde, örneğin olay sürümlerine veya zaman damgalarına bakarak tasarlanmalıdır.
Olay şemalarını sürümlemek
Olaylar zamanla değişir. Bir gün kasko olayına yeni bir alan eklemek gerekir. Bu noktada iki ilke işe yarar: Var olan alanları silmek yerine yeni alanları isteğe bağlı olarak eklemek ve her olayda bir şema sürümü taşımak. Böylece eski aboneler çalışmaya devam ederken yeni aboneler zenginleşmiş veriyi kullanabilir. Kırıcı bir değişiklik kaçınılmazsa yeni bir olay türü tanımlamak, var olanı sessizce değiştirmekten daha güvenlidir.
Olay deposu, mesaj aracısı ve tüketici grupları
Olay tabanlı mimariyi hayata geçirirken üç teknik bileşen öne çıkar. Birincisi olayların kalıcı olarak yazıldığı olay deposudur. Bazı sistemler olayları yalnızca iletir ve unutur; bazıları ise belirli bir süre veya süresiz saklar. Acente yazılımı için olayların en azından denetim ve hata ayıklama için makul bir süre saklanması önerilir. İkincisi olayları abonelere dağıtan mesaj aracısıdır. Bu bir kuyruk sistemi, bir yayın-abone altyapısı ya da daha küçük ölçekte veritabanı tabanlı bir tablo olabilir. Önemli olan, yayıncının abonelerin ayakta olup olmadığını dert etmemesidir.
Üçüncüsü tüketici gruplarıdır. Aynı olayı bildirim servisi de rapor servisi de okur; ancak her biri kendi ilerleme noktasını ayrı tutar. Rapor servisi bir süreliğine dursa bile, yeniden başladığında kaldığı yerden devam eder ve bildirim servisinin çalışmasını etkilemez. Bu bağımsızlık, bakım çalışmalarını ve kademeli güncellemeleri de kolaylaştırır.
Okuma modellerini olaylardan beslemek
Yönetici paneli gibi yoğun okuma yapılan ekranlar, her açılışta onlarca tabloyu birleştirmek yerine olaylardan beslenen hazır özet tablolar kullanabilir. Örneğin "PoliçeleştirmeTamamlandı" olayı geldiğinde şube bazlı günlük özet bir artırılır. Bu yaklaşım, işlem kayıtlarının tutulduğu veritabanını ağır rapor sorgularından korur ve panelin daha akıcı açılmasına katkı verir. Özet tablo bozulursa olaylar baştan okunarak yeniden oluşturulabilir; bu da olayların saklanmasının bir başka pratik faydasıdır.
InsureHub bakış açısı: Olaylar ürünün omurgası
InsureHub, sigorta acentelerine yazılım sağlayan bir platform olarak web paneli, mobil uygulama ve teklif motoru arasındaki iletişimi mümkün olduğunca iş olayları üzerinden kurgulamayı hedefler. Bu yaklaşım sayesinde sigorta teklif programı tarafında başlayan bir işlem, Acente CRM ekranındaki müşteri geçmişine ve mobil sigorta uygulaması tarafındaki bildirimlere aynı olay üzerinden yansıyabilir.
Değerlendirme listesi
Bir acente yazılımının olay modelini anlamak için sağlayıcınıza şu soruları yöneltebilirsiniz:
- Teklif, poliçe ve tahsilat adımları birbirini senkron olarak mı bekliyor, yoksa arka planda mı tetikleniyor?
- Trafik, kasko ve DASK akışları ayrı ayrı izlenebiliyor mu?
- Bir işlemin geçmişi adım adım görüntülenebiliyor mu?
- Yeni bir bildirim ya da rapor ihtiyacı, mevcut akışı değiştirmeden eklenebiliyor mu?
Bu soruların cevapları, yazılımın bugünkü ekranlarından çok yarınki ihtiyaçlarınıza ne kadar kolay uyum sağlayacağını gösterir.