Layered Sistem Nedir? Cesur Bir Eleştiri ve Alternatifler
Layered sistem: Düzeni mi sağlar, yoksa karmaşayı mı cilalar?
Sert bir giriş yapayım: Katmanlı (layered) sistem yıllarca “kurumsal akıl” diye pazarlanan, bugünse birçok projede ilerlemeyi yavaşlatan bir alışkanlık. “UI → Service → Repository → Database” çizgisi, beyaz tahtada estetik durabilir; ama üretim ortamında çoğu zaman esnekliği törpüler, ekipleri yatay silolara hapseder ve değişimi pahalı hale getirir. Bu yazı bir tanım özetinden fazlası: Layered yaklaşımın zayıf yanlarını dürüstçe masaya yatırıp tartışma açıyoruz.
Layered sistem nedir? (ve neden hâlâ bu kadar yaygın?)
Kısaca: Sorumlulukları yatay katmanlara ayıran mimari kalıp. Sunum katmanı kullanıcıyla konuşur, iş katmanı kuralları çalıştırır, veri erişim katmanı veritabanıyla konuşur. Teoride harika: “Ayrık sorumluluk, kolay test, modülerlik.” Pratikte ise şu sorular hep havada kalır:
Değişiklikler gerçekten tek bir katmanda kalabiliyor mu?
Katman sınırları kodu sadeleştiriyor mu, yoksa ek soyutlamalarla şişiriyor mu?
Ekip yapınız bu katmanlarla uyumlu mu, yoksa gereksiz el değiştirmeler mi yaratıyor?
Zayıf noktalar: Kağıt üzerinde düzen, gerçek hayatta sürtünme
1) Değişim dalgalanması (ripple effect).
Basit bir iş kuralı güncellemesi için UI model → servis DTO → domain nesnesi → repository arayüzü → SQL/ORM katmanı boyunca “tılsımlı geçit töreni” yaparsınız. Her katmanda dönüştürme, kopya model ve haritalama… Sonuç? Fazla bağlam, az değer.
2) Anemik domain ve koddaki tekrar.
Kurallar “service”e sıkışır, domain nesneleri veri torbasına döner. Her katmanda neredeyse aynı şeyi söyleyen sınıflar (DTO/VO/Entity) çoğalır. Kod satırı artar, anlam yoğunluğu düşer.
3) Performans ve sohbet eden katmanlar.
Katman sınırları gereksiz “chatty” çağrılara yol açar: Mikro değişiklikler için çok sayıda geçiş, N+1 sorgular, “basit” bir ekran için üç katmanda on dosya… Yük altında bu sohbetin faturası ağırdır.
4) Test edilebilirlik masalı.
Evet, arayüzler birim test yazmayı kolaylaştırabilir. Ama aşırı soyutlama, aşırı mock demektir. Gerçek davranışı gölgeleyecek kadar çok mock, güveni zedeler; testler kırılganlaşır.
5) Organizasyonel uyumsuzluk.
Layered, ekipleri yatay silolara iter: Frontend ekibi bitti der, backend servis bekler, veri ekibi tabloyu “yarın” açar. Dikey uçtan uca değer üretmek yerine, teslimatlar katman katman askıda kalır.
6) Evrim yerine konservatiflik.
Yeni bir iş yeteneği eklemek için katmanların tamamında iz sürersiniz. “Hızlı deney, hızlı öğren” kültürü; CR’larda katman polisini ikna etme ritüeline dönüşür.
Peki hiç mi iyi yanı yok?
Var ama bağlama bağlı. Basit CRUD ağırlıklı kurumsal ekranlar, düzenli raporlama, düzenleyici gereklilikleri yüksek ve ekip rotasyonu sık olan ortamlarda Layered; öğrenmesi/aktarımı kolay bir güvenlik battaniyesidir. Net protokoller, junior’ların hızla bağlanması, klasik monolitlerde tahmin edilebilirlik… Hepsi mümkün. Sorun, kalıbı bağlamdan bağımsız “tek doğru” sanmak.
Tartışmalı noktalar: Dogma mı, araç kutusu mu?
“Katmanlar bağımlılıkları azaltır.” Çoğu projede yeni bağımlılık türü üretir: Dönüştürücü katmanı, mapper cehennemi, “anti-corruption” adı altında kopya modeller. Az bağımlılık değil, farklı biçimde çok bağımlılık.
“Böyle herkes neyin nerede olduğunu bilir.” Evet, ama değer akışını gizleyerek. İş mantığı ekranın bağlamından kopunca, “feature” sahipliği buharlaşır.
“Microservice’lere giden yol Layered’dan geçer.” Tam tersi: Sıkı katman refleksi, servislerin içeride tekrar Layered’a bölünmesine ve dağıtık karmaşıklığın katmerlenmesine neden olur.
Alternatifler: Dikey dilimler, daha az sürtünme
Vertical Slice Architecture (Dikey Dilimleme).
Özellik/akış bazlı örgütlenme: Bir “feature”ın UI+domain+data uçtan uca aynı modülde. Değişim tek yerde, sahiplik net.
Hexagonal / Ports & Adapters.
Katman yerine yön bağımsızlık: Domain merkezdedir; dış dünya port/adaptörlerle bağlanır. Bağımlılık yönetimi daha rasyoneldir, testler davranışa yakınlaşır.
Clean Architecture, Modular Monolith.
Katmanları amaçla yeniden tanımlar: Politikaları detaylardan ayırır, ama zorunlu yatay şeritlere mahkûm etmez. Modüller iş yeteneklerine göre bölünür.
Event-Driven tasarım.
Katmanlar arası çağrı yerine olay akışı; gevşek bağ, yüksek esneklik. Özellikle değişimin hızlı olduğu ürünlerde güçlü seçenek.
Katmanlı mimariyi savunacaksanız: Koruma bantları
DTO patlamasını sınırlayın, dönüştürmeyi minimumda tutun.
Katman sınırlarını “değer akışı” ile doğrulayın; her yeni model için “neden?” diye sorun.
Testlerde “aşırı mock” yerine sözleşme/özellik testi tercih edin.
Organizasyonu dikey sahiplikle hizalayın; teslimatı katmanlar yerine feature ekiplerine verin.
Erken optimizasyon yerine erken öğrenme: Önce deney, sonra kalıplaştır.
Provokatif sorular: Tartışmayı başlatalım
Katmanlı mimari sizin projede gerçekten bağımlılığı azalttı mı, yoksa sadece görünümünü mü değiştirdi?
Bir ekranı uçtan uca değiştirmek için kaç pull request ve kaç ekip gerekiyor? Bu sağlıklı mı?
Layered’ı sürdürmek için harcadığınız enerji, Vertical Slice’a geçişin maliyetini çoktan aşmış olabilir mi?
Domain’inizi “service” isimleriyle mi, yoksa müşterinin değer akışıyla mı düşünüyorsunuz?
Son söz: Layered sistem bir hedef değil, sadece bir araç
Layered sistem, doğru bağlamda “yeterince iyi” olabilir; ama pek çok ürün ekibi için bugün inovasyonun önünde görünmez bir duvar. Kalıpları kutsallaştırmayı bırakalım. Takımların değişim hızını, değer akışını ve öğrenme döngüsünü iyileştiren mimari kazanır. Eğer kodunuzda katmanlar konuşuyor ama kullanıcıya değer geç ulaşsaydı, sorun mimarideki “düzen” değil, düzenin yanlış yerde olmasıdır.
Şimdi sıra sizde: Projenizde ilk kaldıracağınız katman hangisi ve neden? Yorumlarda görüşlerinizi savunun; tartışma ateşini birlikte harlayalım.