Klinik başvuru sisteminde formun arkasındaki süreç

01Formun bittiği yerde başlayan iş

Bir başvuru formu tasarlarken ilk akla gelen şey alanlar oluyor: hangi bilgiler istenecek, hangileri zorunlu olacak, sıralama nasıl kurulacak. Kadir Yücebaş için geliştirdiğim özel projede de işe buradan başlamak cazipti. Ama projenin asıl ihtiyacı başka bir yerdeydi. Başvurunun alınması, klinik ekibine iletilmesi ve sürecin takip edilmesi birbirine bağlı işler. Form ne kadar iyi tasarlanırsa tasarlansın, gönderildikten sonra ne olduğu belirsizse hem başvuru sahibi hem de klinik ekibi bir boşlukta kalıyor.

Bu yüzden sistemi en baştan bir akış olarak düşünmeye çalıştım. Klinik başvurusu ve ön değerlendirme süreci tek bir yapı içinde ele alınıyor. Türkçe ve İngilizce başvuru arayüzleri, klinik yönetim paneli ve bildirim servisleri aynı sistemin farklı yüzleri olarak birlikte çalışıyor. Benim için önemli olan, bu yüzlerin her birinin kendi kullanıcısına anlaşılır gelmesi ve arka planda aynı gerçekliği paylaşması.

02İki dil, tek veri modeli

İki dilli bir başvuru arayüzü kurarken en kolay yol her dil için ayrı bir form yazmak gibi görünebilir. Kısa vadede hızlı, ama uzun vadede iki ayrı gerçeklik üretiyor. Bir alan eklendiğinde ya da bir doğrulama kuralı değiştiğinde iki yeri birden güncellemek gerekiyor ve bir noktada ikisi birbirinden sessizce ayrışıyor.

Bu projede Türkçe ve İngilizce formları ortak şemalar üzerinden aynı veri modeline bağlamayı tercih ettim. Dil, kullanıcının gördüğü metni değiştiriyor, başvurunun yapısını değiştirmiyor. Böylece yönetim panelinde bir başvuru açıldığında, hangi dilden geldiğinden bağımsız olarak aynı biçimde okunabiliyor. Ortak şemaların bir faydası daha var: arayüzün yaptığı kontrol ile sunucunun kabul ettiği veri aynı tanımdan besleniyor. Bu, iki katman arasında fark edilmeden oluşan uyumsuzlukları azaltıyor.

Türkçe başvuru arayüzü   ──┐
İngilizce başvuru arayüzü ──┼──> ortak şemalar ──> servis katmanı ──> Drizzle + PostgreSQL
Klinik yönetim paneli     ──┘                            │
                                                         └──> e-posta bildirimi ve belge üretimi

03Yönetim tarafı da bir kullanıcı arayüzü

Bu tür projelerde yönetim paneli çoğu zaman ikinci planda kalıyor. Başvuru sahibinin gördüğü ekranlar özenle hazırlanıyor, ekibin her gün kullandığı ekranlar ise iç araç sayıldığı için aceleyle geçiştiriliyor. Ben tam tersini düşünüyorum: süreci yürütecek olan kişi yönetim panelini kullanan kişi. Başvuruyu nasıl gördüğü, hangi bilgiye ne kadar hızlı ulaştığı ve bir sonraki adıma nasıl geçtiği, sürecin kalitesini doğrudan belirliyor.

Klinik yönetim panelinde başvuruların incelenmesi ve durumlarının takip edilmesi aynı akışın parçaları. Buradaki amacım, ekibe fazladan iş çıkarmayan ama sürecin nerede olduğunu her zaman görünür kılan bir yapı kurmak. Sağlıkla ilgili bir bağlamda çalışırken bir sınırı da bilinçli olarak koruyorum: sistem değerlendirme yapmıyor, değerlendirmeyi klinik ekibi yapıyor. Yazılımın görevi bilgiyi düzenli ve eksiksiz biçimde doğru kişiye ulaştırmak.

Form sürecin başlangıcı, asıl iş gönderildikten sonra başlıyor.

04Durum takibi ve bildirimler

Başvuru sahibi açısından en rahatsız edici şey belirsizlik. Bir form gönderip hiçbir geri dönüş alamamak, sürecin işleyip işlemediğini merak ettiriyor. Bu yüzden durum takibini sistemin merkezine yakın bir yerde düşündüm. Başvurunun bir durumu var ve bu durum, hem yönetim tarafında hem de başvuru sahibinin süreci izleme biçiminde anlam taşıyor.

Bildirim ve e-posta akışları burada devreye giriyor. Nodemailer üzerinden çalışan e-posta tarafı, sürecin belirli anlarında ilgili taraflara bilgi taşıyor. Belge üretimi bileşeni de başvurudaki bilgilerin düzenli bir çıktıya dönüşmesini sağlıyor. Bu tür akışlarda tercih ettiğim yaklaşım, bildirimleri başvurunun durumuna bağlı düşünmek. Bir e-postanın gönderilmesi, bir yerlerde ayrıca hatırlanması gereken bir kural olduğunda unutulmaya açık hale geliyor. Durumla birlikte ele alındığında hem tutarlılık artıyor hem de akış ileride değiştiğinde nereye dokunulacağı belli oluyor.

05Veri katmanı ve çalışma ortamı

Next.js uygulamaları, Drizzle ve PostgreSQL üzerinden aynı veri katmanını paylaşıyor. Drizzle'ı sevmemin sebebi, şema tanımının TypeScript tarafında açıkça okunabilmesi ve sorguların tiplerle birlikte yazılabilmesi. Başvuru gibi alanları zamanla değişebilecek bir yapıda, veritabanı şemasının kodla aynı yerde görünmesi değişiklikleri daha güvenli kılıyor. Docker ise geliştirme ve çalışma ortamlarının birbirine yakın kalmasına yardım ediyor.

Bu projede web, servis ve veri katmanlarının hepsinde çalışıyorum. Bunun avantajı, bir değişikliğin formdan veritabanına, oradan yönetim paneline ve bildirime kadar nasıl yayıldığını tek bir zihinde takip edebilmek. Dezavantajı ise bu bütünlüğü korumanın disiplin gerektirmesi. Ortak şemalar ve tek veri modeli, bu disiplinin en somut aracı.