Bu yazımızda özellikle bankacılık sistemlerinde kullanılan arayüzleri nasıl daha kolay ve güvenli olarak geliştirebiliriz konularını ele alacağız.

Genel Problemler

Ana bankacılık uygulamaları genelde şu yapı üzerinde kurulmuştur.

Bir tane arayüz kütüphanesi seçilir ve bu kütüphane üzerine şirketler kendi component yapılarını geliştirirler. İster web tabanlı olsun, ister masaüstü tabanlı genelde bu yaklaşım benimsenmektedir.

Burada başlıca şu sorunlar yaşanmaktadır;

1. ‘Business Logic’ diye tabir edilen iş kurallarını nereye kodlayacağız? Server kısmına koymamız tavsiye ediliyor ama nasıl? Server kodlarından UI elementlerine erişemiyoruz.
   
   Örnek: Eğer ekranı açan kullanıcı A birimine ait bir kullanıcı ise ekrandaki tutar alanı ‘readonly’ olsun.
   
   Bu örnekte olduğu gibi onlarca iş kuralı olduğunu hayal edin.
2. UI Event döngüsünün etkilerini nasıl minimize edebiliriz.
   
   Örnek bir senaryo üzerinden değerlendirecek olursak;
   Ekrandaki tutar alanının davranışı şöyle olsun.

• X rolündeki kullanıcı açarsa disable olsun,
• Y rolünde kullanıcı açarsa enable olsun,
• Z rolünde kullanıcı açarsa alan hiç gözükmesin.
• Ekrandaki şehir seçimi değiştiğinde ve seçilen şehir A ise tutar alanı disable olsun B combosunun değerleri şöyle olsun.
  
  Anlaşılacağı üzere zamanla bu istekler ekranı daha da karmaşık hale getirecek ve artık ekrandaki bir alanı değiştirdiğinizde zincirleme olarak birçok alan değişecek ve bunu yönetmek oldukça zor bir hale gelecek.

3. Analist olan bir kişi yazılımcıdan bir label değiştirmesini istediğinde yazılımcının bir label için bile olsa o projeyi açıp o ilgili yeri bulup değişikliği yapması gerekiyor.
   
   Peki buna gerçekten gerek var mı? Analistlerin de müdahale edebileceği bir yaklaşım olamaz mı? Analist düşündüğü ekranı kağıtta çizip anlatmak yerine daha güzel bir yaklaşım olabilir mi?

4. Her yazılımcının kendine ait bir kodlama stili bulunuyor. Kimisi eventbus kullanarak, kimisi callback kullanarak birçok farklı kodlama stili ile kodluyor olabilir.
   
   Yazılımcıların ortak bir mantıkta ve şirketin belirlediği kodlama stiline uygun olarak kodlamasını nasıl sağlarız?

5. Web projelerindeki zorluklar. Callbackler, eventler, react event döngüleri, typescript zorlukları, custom css verilmesi.

6. UI teknolojileri sürekli olarak değişiyor. Bir zamanlar Windows form vardı, sonrasında Xaml ortalığı kasıp kavurdu, şimdilerde ise react-angular-vue veya muadili teknolojiler kullanılıyor. Qwik gibi teknolojiler ise şimdiden pazarda pay sahibi olmaya çalışıyor. Bu değişikliklerden minimum derecede nasıl etkileniriz.
   
   Eğer siz tüm bankacılık ekranlarınızı WPF üzerinde yaptıysanız ve çoğu iş kuralınız clientside kodlarınızda ise web teknolojisine geçmeniz oldukça zahmetli olacaktır.

7. Ekranların yavaş yüklenme sorunu. Component’lerin birbirlerini tetiklediği ve bazı tetiklenmeler sonucu client kısmından server kısmına tekrar request göndermeniz gerektiği durumlar olur.
   
   Bu durumlarda ekran yüklenirken 5-6 kez server’a istek gönderiyor olabilir ve bu sebeple ekranının yavaş açılır.

Yaşadığımız genel sorunları ortaya koyduğumuza göre artık çözüm olarak ne yapabiliriz ona odaklanabiliriz.

Arayüz Tasarlayıcısı

Şöyle bir arayüz tasarlayıcı hayal edelim.

Analist olan kişi ekranın nasıl bir görünüme sahip olacağını, ekrandaki hangi alanın veri tabanındaki hangi kolona karşılık geldiğini sürükle-bırak yaparak bir ekran üzerinde tasarlayacak.

Sonrasında ilgili yazılımcı bu tasarım üzerine eklenecek olan iş kurallarını server kısmında bulunan kod kısımlarını kodlayacak ve ekran bu tasarım üzerinden otomatik olarak UI kodları üretilecek ve ekran bu şekilde bitmiş olacak.

Kısaca çalışma mantığı şöyledir.

Yukarıdaki resimde görüldüğü üzere ekranın tüm datası bir request üzerine bind edilmiştir. Bu requesti client-server arasında bilgi taşıyan bir paket olarak düşünebilirsiniz.

Bu tarz bir yaklaşımın hangi sorunları nasıl çözdüğüne bir bakalım.

• Developer client tarafında herhangi bir typescript-css-javascript kodu yazmıyor. Böylelikle web kodlamalarındaki zorluklardan kurtuluyoruz.

• İş kuralları tamamıyla serverside tarafında kodlanıyor. Client tarafında hiçbir if cümlesi yazılmamış oluyor.

• UI kısmında teknoloji bağımsız bir kod sisteminiz olmuş oluyor. Ekranları ister web(react.js) için, ister WPF için üretebilirsiniz. Böylelikle ilerde çıkabilecek yeni bir UI teknolojisine veya ürününüzü sattığınız firmanın kullandığı UI teknolojisine daha kolay çevirebilirsiniz. Mesela yazdığınız ürünü sattığınız bir firma WPF teknolojisini kullanıyor başka sattığınız bir firma ise web-angular temelli teknoloji kullanıyor olsun. Hiçbir ekranı tekrar yazmaya gerek kalmadan arayüzleri iki firma için wpf ve web için ayrı ayrı ürettirebilirsiniz.

• Ekranın %70’ini analistler tasarlayabilir. Böylelikle analist ve yazılımcı arasındaki iletişimi daha etkin bir hale getirmiş olursunuz.

• Yazılımcının kendine ait farklı farklı tarzda kod yazmasını engellemiş olursunuz. Çünkü yazılımcı istese de client tarafına bir kod yazamıyor. Mecbur server kısmında istenen yapıda kodlama yapmak durumunda kalıyor.

• Componentlerin arasındaki iletişim bilgisi server kısmında olduğu için ekran tek seferde yükleniyor, dolayısıyla ekran daha hızlı yükleniyor olacaktır.

Sonuç

Bu bahsi yapılan Tasarım Ekranı hayali bir konu değildir.

Architecht olarak özellikle Kart modülü ekranlarında 600’den fazla ekran kısa bir süre içinde bu şekilde kendi tasarlayıcımız ile geliştirilmiştir.

Böylelikle ekranlara ait tüm iş mantığı içeren kodlar sunucu tarafında konumlandırılmış oldu. Bu sayede arayüzü iş mantığı içeren kodlardan tamamen ayırmış olduk. Hatta arayüzü teknoloji bağımlılığından dahi kurtarmış olduk. Artık arayüzü isterseniz wpf ile isterseniz react.js ile veya başka herhangi bir UI teknolojisi ile entegre edebilecek bir yere konumlandırmış olduk.