Ortak kimlik, ayrı kurallar: OYS & TYS monoreposundan notlar

01İki sistem, tek depo

OYS & TYS; öğrenci ve kurs yönetimi ile Türkçe Yeterlik Sınavı süreçlerini ortak bir platform yapısında ele alan sistemler. Öğrenci, kurs, sınav ve yönetim süreçlerine odaklanıyor ve bir monorepo içinde geliştiriliyor. Arayüzler Next.js, servisler NestJS ile yazılıyor; veri tarafında PostgreSQL, Prisma ve Redis var. Depo yapısını Turborepo yönetiyor. Bu web tabanlı yönetim sistemlerinin frontend ve backend çalışmalarında aktif rol alıyorum ve öğrenci, kurs ve sınav yönetimi kapsamındaki geliştirmeler devam ediyor.

Bu notta belirli bir özellikten çok, bu tür bir yapıda sürekli karşıma çıkan bir gerilimden bahsetmek istiyorum: ortak olanı paylaşmak ile ayrı olanı ayrı tutmak arasındaki gerilim.

02Ortak olan ne

Öğrenci, öğretici, aday ve yönetici ihtiyaçları birbirine bağlı. Aynı kişi farklı zamanlarda farklı rollerde sisteme girebilir; giriş, oturum ve temel kullanıcı bilgisi gibi konular her alanda tekrar yazılmamalı. Ortak kimlik altyapısı bu yüzden yapının merkezinde duruyor. Turborepo da tam bu noktada işe yarıyor: ortak paketler ile farklı uygulama alanlarının aynı depoda yönetilmesini sağlıyor.

Paylaşmanın getirisi açık. Bir kural bir kez yazılıyor, bir tip tanımı her yerde aynı anlama geliyor, bir düzeltme bütün uygulamalara aynı anda ulaşıyor. Ama paylaşımın da bir maliyeti var ve bence bu maliyet çoğu zaman geç fark ediliyor.

Turborepo
  ortak paketler      : kimlik altyapısı, paylaşılan tipler ve araçlar
  öğrenci ve kurs alanı : Next.js arayüz  ->  NestJS servis
  sınav alanı          : Next.js arayüz  ->  NestJS servis
  veri                 : PostgreSQL + Prisma, Redis

03Ayrı kalması gereken ne

Her alanın veri ve iş kuralları farklı. Bir kursun yaşam döngüsü ile bir sınav sürecinin yaşam döngüsü aynı değil; bir öğrencinin kayıt durumu ile bir adayın sınav durumu aynı soruların cevabı değil. Bu kuralları “ortak” bir pakete taşımak ilk anda düzenli görünebilir, ama zamanla o paket iki alanın da istisnalarını taşıyan bir yere dönüşür.

Benim bu konudaki yaklaşımım şu: ortak pakete yalnızca gerçekten ortak olan girer. Kimlik, ortak tipler, genel araçlar paylaşılabilir. Bir alanın iş kuralı, başka bir alan da benzer bir şeye ihtiyaç duyuyor diye ortaklaşmaz. Benzerlik ile aynılık arasındaki fark, monorepo'da en sık yanılınan yer. Bir paketi ortaklaştırmak kolay, sonradan ayırmak çok daha zor; bu yüzden emin olmadığım durumlarda ayrı tutmayı tercih ediyorum.

Ortak kimlik, açık sorumluluklar.

04Kullanıcı akışı ve servis sınırı

Bu çalışmada kullanıcı akışlarını veri ve servis sınırlarıyla birlikte düşünmeye odaklanıyorum. Bir ekranda kullanıcıya akıcı görünen bir iş, arka planda birden fazla alana dokunuyor olabilir. Böyle durumlarda kolay yol, bir servisin diğer alanın verisine doğrudan ulaşması. Ama bu, sınırın sessizce delinmesi demek.

Frontend ve backend'de birlikte çalışmanın burada bir avantajı var: bir akışın iki ucunu da gördüğüm için, sınırı nerede çizeceğimi daha bilinçli seçebiliyorum. Arayüzdeki bir ihtiyacı karşılamak için servisin sorumluluğunu genişletmek yerine, iki alan arasındaki konuşmayı açık bir sözleşmeye bağlamak uzun vadede daha sağlıklı görünüyor.

05Monorepo bir disiplin gerektiriyor

Monorepo her şeyi aynı yerde tutmayı kolaylaştırıyor; bu yüzden her şeyin birbirine bağlanmasını da kolaylaştırıyor. Aynı depoda olmak, aynı modül olmak anlamına gelmiyor. Bağımlılıkların yönünü bilinçli tutmak, bir alanın diğerinin iç detayına erişmemesine dikkat etmek ve ortak paketlere ne girdiğini sorgulamak bence bu yapının asıl işi. Kural basit görünüyor, ama günlük işin temposunda en kolay unutulan şey de bu.

Redis gibi paylaşılan bir altyapı parçası da aynı soruyu doğuruyor. Altyapının ortak olması, içinde tutulan şeylerin sahipsiz olabileceği anlamına gelmiyor. Her alanın kendi verisinin sahibi olması, ortak kaynak kullansa bile korunması gereken bir ilke.

06Devam eden bir denge

Geliştirme sürdüğü için bu dengeyi tamamlanmış bir şey gibi anlatmıyorum. Her yeni ihtiyaçta “bu ortak mı, yoksa sadece benzer mi” sorusu yeniden soruluyor. Ortak altyapı kurarken her alanın kendi kurallarını koruması, bir kez verilip unutulan bir karar değil; sürekli bakım isteyen bir alışkanlık. Bu soruyu açıkça sormak, kod incelemelerinde de faydalı bir alışkanlık.