3 Katmanlı Mimari Nedir? “Eski Düzenin Şık Üniforması”
“3 katmanlı mimari harikadır” klişesini çöpe atmakla başlayalım. Evet, sunum (UI), iş mantığı (business) ve veri erişimi (data) şeklindeki ayrım, bir dönem kod kalabalığını dizginledi. Ama bu şık üniforma, her probleme aynı kıyafeti giydirmeye çalıştığımızda bizi yanıltıyor. Katmanlar arası katı sınırlar üretirken, ekipler arası akışı yavaşlatıyor; çevik olmak istediğimiz anda, protokol töreni başlatıyor.
Temeller: Üç Katmanın Kısa Anatomisi
- Sunum Katmanı (Presentation): Kullanıcıyla konuşur. HTML/JS, mobil UI, API gateway.
- İş Mantığı Katmanı (Business): Kuralları uygular, süreçleri koordine eder.
- Veri Katmanı (Data): Kalıcılık, sorgular, ORM, cache, mesaj günlüğü.
Bu sınıflama kağıt üzerinde temiz görünür; fakat pratikte çizgiler bulanıklaşır: iş kuralları veri erişiminde sızar, sunum katmanı “ince” kalayım derken API şişer.
Avantajlar: Gerçek mi, Romantizm mi?
Net Sorumluluk, Test Edilebilirlik, Ekip Ayrımı
Evet, ayrım prensibi (separation of concerns) ve tek sorumluluk ilkesi (SRP) desteklenir. Testler izole edilebilir. Ekipler katmanlara göre organize olabilir. Fakat bu avantajlar çoğu zaman organizasyon tasarımı ile sağlanmalıdır; mimariyi bir idare biçimine çevirdiğinizde kod, şemaya değil bürokrasiye uyar.
Gerçek Maliyetler: Gecikme, “Katman Çenesi”, Anemik Domain
- Ağ sıçramaları ve gecikme: “UI → BLL → DAL → DB” ritüeli, yüksek çağrı hacminde milisaniyeleri saniyeye çevirir.
- Chatty interfaces: İnce katmanlar, çok konuşan sınırlara dönüşür. Bir iş adımı için çok sayıda küçük çağrı.
- Anemik domain modeli: Kurallar “service” dosyalarında dağılır, varlıklar (entities) ise yalnızca torba hâline gelir.
- ORM bağımlılığı: Model, veritabanının gölgesine hapsolur; iş kuralı veri şemasına eğilir.
- Dağıtık işlemler kâbusu: Tek veritabanından çıkar çıkmaz, iki-üç kaynak arasında tutarlılığı kim sağlayacak?
Tartışmalı Noktalar: “Katman ≠ Modül”, “Şema ≠ Mimari”
Katmanlar Modülerlik Değildir
Katman, teknik eksene göre ayrımdır; modülerlik ise iş eksenine göre ayrımdır. “Sipariş”, “Ödeme”, “Stok” gibi iş modüllerini üç katmana bölmek; davranışı dağıtır, değişikliği pahalılaştırır. Bir modülün içinde sunum-mantık-veri düzeni olabilir; ama sistemi katmanlara göre değil, domain’e göre bölmek çoğu zaman daha verimlidir.
Şema Saplantısı
“Önce veri şemasını çizelim” yaklaşımı, iş kurallarını SQL’e, kimliği de otomatik ID’ye indirger. Sonuç: esnek olması gereken iş süreci, migration senaryolarının mahkûmu olur. Mimariyi şema değil, kullanım bağlamları (use case’ler) yönlendirmelidir.
Modern Dünyada 3 Katman: Nerede Tökezler?
Olay Odaklı (Event-Driven) Sistemlerde Sürtünme
Katmanlı akış senkron düşünür. Oysa modern sistemler, event stream, outbox ve eventual consistency ile çalışır. 3 katman, bu akışları “service → repository” kalıbına sıkıştırınca zaman boyutu (gecikmeli doğruluk) görünmez olur.
Bulut-Doğal (Cloud-Native) Gerçeklik
Yatay ölçek, edge cache, CQRS, read model’ler… Katmanlar arası tek tip boru hattı, farklı okuma/yazma modellerini boğar. API kompozisyonu, BFF (Backend-for-Frontend) gibi pratikler, katmanları esnetmenizi ister; çoğu 3 katman şablonu buna dirençlidir.
Gerçek Zamanlı Deneyimlerde
Sohbet, oyun, canlı analiz gibi düşük gecikmeli işlerde katman geçişleri ile validation/de-serialization tekrarları, verimi yer.
Alternatifler: Dogma Değil, Araç Kutusu
Hexagonal/Ports & Adapters
İş çekirdeğini dış dünyadan (UI/DB/Mesajlaşma) portlarla ayırır; bağlam bağımsız test ve kolay teknoloji değişimi sağlar. Katmanlardan daha yönlü ve esnek bir soyutlama.
DDD + Bounded Context
Sistemi katmanlara değil, anlamlı iş bağlamlarına (Sipariş, Fatura, Envanter) böl. Her bağlamda kurallar derli toplu kalır; veri şeması iş diline uyar.
CQRS & Event Sourcing
Okuma ve yazmayı ayır; performansı ve evrimi yönet. Katman geçişi sayısı yerine akı tasarla.
Ne Zaman 3 Katman Mantıklı?
Basit CRUD, Monolit, Tek Takım
Kapsam küçük, domain sade, ekip az ve deneyim kısıtlıysa 3 katman, öğretici bir iskelet olabilir. Net sınırlar hatayı azaltır, onboarding’i kolaylaştırır. Ama ilk fırsatta domain’e göre modülerleştirmeye geçmek akıllıcadır.
Kurumsal Mirasta Yara Bandı
Var olan monolitlerin “temizlenmesi” sürecinde, katmanlaştırma ara adım olarak işe yarar; fakat son durak değildir. Kademeli olarak modüllere ayırmayı, bounded context’lere bölmeyi planlamadan 3 katmanda kalmak sadece boruyu boyamaktır.
Provokatif Sorular: Sizi Savunmadan Düşünmeye Zorluyor
- Ürün ekibiniz değişiklik hızını “katman sınırları” yüzünden mi kaybediyor?
- Bugünkü 3 katmanınız, domain kurallarını görünür kılıyor mu, yoksa service dosyalarında buharlaştırıyor mu?
- Bir özelliği dağıtık hâle getirirken, katmanlarınız event akışlarını nasıl temsil ediyor?
- Modüllerinizi iş bağlamına göre bölseniz, kaç dosyada değişiklik yapmanız gerekir?
- Yük altında gecikmeyi katman geçişleri mi, yoksa veritabanı mı belirliyor—ölçtünüz mü?
Sonuç: Şablon Değil, Strateji Seçin
3 katmanlı mimari iyi bir başlangıç olabilir; ancak modern ürünlerde tek doğru değildir. Sorunlarınız katman eksikliğinden değil, yanlış sınır çiziminden doğuyor olabilir. Mimariyi diyagramla değil, değişim akışı ve gerçek kullanıcı davranışı ile doğrulayın.
Söz Sizde
Sizce 3 katman, ekibinizin hızını artırıyor mu yoksa frenliyor mu? Domain’e göre modülerleşme deneyiminizde neler iyi gitti, neler tökezledi? Yorumlarda karşı örneklerinizi, metriklerinizi ve itirazlarınızı paylaşın; tartışmayı gerçek verilerle büyütelim.