Acente yazılımlarında sık rastlanan bir tasarım yanılgısı, bütün sigorta sorgularını tek bir genel "teklif" yapısı altında toplamaya çalışmaktır. İlk bakışta mantıklı görünür: Her branşta bir sorgu başlar, şirketlere istek gider, fiyatlar gelir ve kullanıcı birini seçer. Ancak trafik, kasko ve DASK sorgularının ayrıntılarına inildiğinde bu üç akışın girdi verileri, doğrulama kuralları, dış sistem bağımlılıkları ve sonuç yapıları birbirinden belirgin biçimde ayrışır. Bu farkları tek bir yapıda toplamak, kod tabanında giderek büyüyen koşullu dallanmalara ve kırılgan bir sisteme yol açar.
Üç branş, üç farklı veri dünyası
Trafik sorgusu
Zorunlu trafik sigortası sorgusu araç odaklıdır. Plaka, ruhsat bilgileri ve araç sahibine ait kimlik bilgileri temel girdilerdir. Araç bilgilerinin resmi kaynaklardan doğrulanması akışın erken bir adımıdır. Teminat yapısı büyük ölçüde standart olduğu için sonuçlar daha çok fiyat ve ödeme seçenekleri üzerinden karşılaştırılır.
Kasko sorgusu
Kasko da araç odaklıdır ama çok daha fazla değişken içerir. Aracın kullanım şekli, ek teminatlar, muafiyet tercihleri, aksesuar bilgileri ve şirkete göre değişen paket yapıları sorguyu zenginleştirir. Sonuçlar yalnızca fiyatla değil, teminat kapsamıyla birlikte değerlendirilmelidir. Bu nedenle kasko sonuç yapısı, trafik sonuçlarına göre çok daha katmanlıdır.
DASK sorgusu
DASK ise tamamen farklı bir eksende çalışır. Araç yerine konut söz konusudur. Adres bilgisinin ulusal adres kayıt sistemindeki karşılığıyla eşleştirilmesi, yapı tarzı, inşa yılı ve brüt alan gibi bilgiler sorgunun merkezindedir. Araç tabanlı doğrulama adımlarının hiçbiri burada geçerli değildir; bunun yerine adres doğrulama kritik bir ön adımdır.
Tek yapıda toplamanın bedeli
Bu üç branşı ortak bir şema ve tek bir servis içinde yönetmeye çalışmak birkaç somut soruna yol açar:
- Anlamsız alanlar: Ortak şemada plaka alanı DASK için, adres kodu alanı trafik için boş kalır. Hangi alanın hangi branşta zorunlu olduğu şemadan anlaşılmaz.
- Koşul yığınları: Doğrulama, eşleme ve sonuç işleme kodlarının her biri branşa göre dallanır. Bir branşa yapılan değişiklik, diğer branşlarda beklenmedik hatalara neden olabilir.
- Ortak arıza noktası: Kasko tarafındaki yoğun bir şirket entegrasyonu sorunu, aynı servis içinde çalışan trafik ve DASK sorgularını da yavaşlatır.
- Test zorluğu: Her değişiklikte üç branşın bütün senaryolarının yeniden test edilmesi gerekir.
Branş odaklı servis sınırları
Daha sağlıklı yaklaşım, her branşı kendi sınırları olan bir alan olarak modellemektir. Bu, mutlaka üç ayrı fiziksel servis anlamına gelmez; aynı uygulama içinde net ayrılmış modüller de olabilir. Önemli olan sınırların kodda ve veri modelinde açıkça görünmesidir. Her branş alanı şu bileşenlere sahip olur:
- Branşa özel girdi şeması: Yalnızca o branş için anlamlı alanları içerir ve zorunluluk kuralları açıktır.
- Branşa özel doğrulama: Trafik ve kasko için araç doğrulama, DASK için adres doğrulama adımları kendi alanlarında yer alır.
- Şirket adaptörleri: Her sigorta şirketinin o branştaki servisiyle konuşan ayrı adaptörler bulunur. Bir şirketin kasko servisindeki değişiklik, aynı şirketin trafik adaptörüne dokunmaz.
- Branşa özel sonuç modeli: Kasko için teminat ayrıntıları, trafik için standart teminat ve ödeme seçenekleri, DASK için konut bilgileriyle eşleşen sonuç yapısı ayrı tanımlanır.
Ortak olan ne kalır?
Ayrıştırma her şeyi kopyalamak anlamına gelmez. Bazı yetenekler gerçekten bütün branşlar için ortaktır ve paylaşılan bir katmanda yer almalıdır:
- Müşteri kartı ve iletişim bilgileri
- Sorgu yaşam döngüsü durumları: başlatıldı, sürüyor, tamamlandı, hata
- Kuyruk, yeniden deneme ve devre kesici gibi dayanıklılık altyapısı
- Kimlik doğrulama, yetkilendirme ve denetim kayıtları
- Teklif sonucunun müşteriye sunulması ve poliçeleştirme adımına geçiş
Doğru denge, branşa özgü olanı ayırıp gerçekten ortak olanı paylaşmaktır. Ortak katman, branşlar hakkında ayrıntı bilmeden, yalnızca tanımlı arayüzler üzerinden onlarla konuşmalıdır.
Branş ayrımının ekranlardaki karşılığı
Mimari ayrım, kullanıcı ekranlarında da kendini gösterir. Her branş için ayrı bir sorgu formu, o branşın gerektirdiği alanları doğru sırayla ve anlamlı yardım metinleriyle sunar. Kullanıcı DASK formunda araç bilgisi görmez, trafik formunda adres koduyla uğraşmaz. Sonuç ekranları da branşın doğasına göre şekillenir: Kasko sonuçlarında teminat karşılaştırması öne çıkarken trafik sonuçları daha sade bir liste olarak sunulabilir.
Yeni branş eklemek
Branş odaklı mimarinin en büyük faydalarından biri genişletilebilirliktir. İleride tamamlayıcı sağlık veya konut sigortası gibi yeni bir branş eklenmek istendiğinde mevcut üç branşın koduna dokunmak gerekmez. Yeni branş kendi şeması, doğrulaması, adaptörleri ve sonuç modeliyle eklenir; ortak katmana yalnızca kaydolur.
Test ve izleme stratejisi
Branş sınırlarının net olması test stratejisini de sadeleştirir. Her branş için ayrı bir test seti tutulur; trafik adaptöründe yapılan bir değişiklik yalnızca trafik testlerini tetikler. Uçtan uca testler ise ortak katmanın üç branşla doğru konuştuğunu doğrulamaya odaklanır. İzleme tarafında da benzer bir ayrım gerekir: Sorgu süreleri, hata oranları ve zaman aşımları branş bazında ayrı ayrı ölçülmelidir. Tek bir ortalama değer, örneğin DASK tarafındaki adres doğrulama gecikmesini trafik sorgularının hızlı yanıtları arasında gizleyebilir.
Şirket adaptörlerinin branş bazında ayrılması, sorun anında hızlı karar vermeyi de kolaylaştırır. Bir şirketin kasko servisinde sorun varsa yalnızca o adaptör devre dışı bırakılabilir; aynı şirketin trafik ve DASK sorguları çalışmaya devam eder. Bu ince ayar, tek parça bir teklif servisinde mümkün değildir.
InsureHub tasarım ilkesi
InsureHub, sigorta acentelerine yazılım sağlarken trafik, kasko ve DASK sorgularını ayrı akışlar olarak ele alır. Bu ayrım sigorta teklif programı ekranlarındaki form yapısından, arka plandaki şirket adaptörlerine kadar uzanır. Aynı ilke mobil sigorta uygulaması tarafında da korunur; böylece sahada başlatılan bir DASK sorgusu ile ofiste hazırlanan bir kasko sorgusu kendi kurallarıyla, birbirini etkilemeden ilerler.