Katmanlı mimari nedir, hâlâ doğru seçim mi?

Katmanlı mimari bugün hâlâ geçerli, ama her projede otomatik tercih olmamalı. Kurumsal, uzun ömürlü, ekiplerin sık değiştiği projelerde güçlü bir iskelet sunar. Ancak yüksek ölçek, yoğun entegrasyon ve bağımsız dağıtım isteyen sistemlerde tek başına yeterli olmaz. Mimari kararı verirken ekip yapısını, büyüme hızını ve değişim baskısını birlikte düşünmek gerekir.

Katmanlı mimarinin temel kavramları

Katmanlı mimariyi anlamak için önce “sorumluluk ayrımı” kavramını netleştirmek gerekir. Her katman belirli bir sorumluluğu üstlenir ve diğer katmanlarla tanımlı yollar üzerinden konuşur. Bu sayede kodu zihinde tutmak, ekibe yeni geliştirici katmak ve değişiklik yönetmek daha kolay hale gelir.

Geleneksel yaklaşımda üç ana katman görürüz. Sunum, iş kuralları ve veri erişimi. Ancak modern projelerde bu yapı esner, bazen daha fazla katman eklenir, bazen bazı katmanlar sadeleşir. Yine de temel fikir değişmez. Her katman sadece kendi işini yapar ve üst katmana hizmet verir.

Bu mimariyi taşıyan en kritik nokta, katmanların bağımlılık yönüdür. Üst katmanlar alt katmanlara bağımlıdır, tersi olmaz. Yani kullanıcı arayüzü, iş mantığını bilir; iş mantığı ise veri katmanını tanır. Veri tarafı ise arayüzü hiç bilmez. Bu akış bozulduğunda mimari hızla dağılır. Mevcut bir kod tabanında akışın nerede bozulduğunu görmek, yazılım mimarisi danışmanlığı kapsamındaki incelemenin ilk adımıdır.

Özetlemek için temel kavramları şöyle sıralayabilirim:

• Sorumluluk ayrımı: Her katman tek bir amaca odaklanır.
• Bağımlılık yönü: Üstten alta doğru tek yönlü akış.
• Katmanlar arası sözleşme: Arayüzler, DTO’lar, public tipler.
• Sızmayı engelleme: Veri detaylarını üst katmanlardan gizleme.

Basit bir örnek düşünün. Web arayüzünde bir form doldurursunuz. Sunum katmanı bu formu işler, iş katmanına bir string ve sayısal parametreler gönderir. İş katmanı kuralları uygular, veri katmanı ise sadece kayıt ve okuma ile ilgilenir. Herkes rolünü bilir.

N katmanlı mimarinin katmanları

N katmanlı yapı, üç katmanlı klasik modelin daha esnek ve detaylı halidir. Burada “N” sabit değildir. Projenin karmaşıklığına, ekiplerin uzmanlık alanlarına ve dağıtım ihtiyaçlarına göre artar veya azalır. Yine de her katman için aynı ilke geçerlidir. Net bir sınır, belirli bir sorumluluk ve kontrollü bağımlılık.

Tipik bir N katmanlı mimari içinde şu yapı sık görülür:

• Sunum katmanı (web, mobil, API uçları)
• Uygulama katmanı (use case, orkestrasyon)
• Domain / iş kuralları katmanı
• Altyapı ve veri erişim katmanı

Bu katmanlar bazen ayrı projeler, bazen aynı çözüm içinde dizinler olarak yer alır. Örneğin .NET dünyasında sunum için bir web projesi, iş mantığı için ayrı bir class library, data erişimi için başka bir library görürsünüz. Java ekosisteminde benzer ayrımı modüller veya paketler üzerinden kurarsınız.

“N” sayısını belirlerken her ek katmanın bir maliyet getirdiğini unutmamak önemli. Fazla katman, özellikle küçük ekiplerde, gereksiz soyutlama ve zor anlaşılır kod üretir. Ben genelde küçük ürünlerde daha az katman öneririm. Geniş kurumsal yapılarda ise uygulama ve domain katmanını net ayırmak, uzun vadede ciddi fayda sağlar.

Bulut ortamlarında N katmanlı mimariyi sadece kod düzeyinde değil, dağıtım topolojisinde de görürsünüz. Web app, arka plan işçileri, veri tabanı, cache ve mesaj kuyruğu ayrı bileşenlerdir. Kod tarafındaki katmanlar ile bu fiziksel bileşenleri birbiriyle uyumlu tasarlamak gerekir.

Uygulama katmanı

Uygulama katmanı, senaryoları yöneten ve akışı kontrol eden orta katmandır. Burada genelde “use case” mantığı kurarsınız. Örneğin “Sipariş oluştur” işlemi tek bir servis içinde toplanır. Bu servis domain kurallarını çağırır, veri katmanından repository kullanır ve dış servislerle konuşur. Uygulama katmanında iş kuralı gömülü tutmazsınız, sadece orkestrasyon yaparsınız.

Veri katmanı

Veri katmanı, data ile ilgili tüm detayların toplandığı bölümdür. Burada tablolar, koleksiyonlar, sorgular ve bağlantı yönetimi yer alır. Üst katmanlar bu detayları görmez. Onlar sadece arayüzler ve basit tipler üzerinden istek yapar. Bu sayede veri tabanını değiştirmek istediğinizde üst katmanları daha az etkilersiniz. Doğru soyutlama burada kritik rol oynar.

Katmanlı mimarinin avantajları

Katmanlı mimarinin en büyük avantajı, karmaşık sistemleri parçalara ayırarak yönetilebilir hale getirmesidir. Her katman kendi bağlamında sade kalır. Yeni bir geliştirici, öncelikle tek bir katmana odaklanarak işe başlayabilir. Bu, özellikle kurumsal projelerde ciddi bir öğrenme kolaylığı sağlar.

Bu yaklaşımın sağladığı pratik faydaları şöyle özetleyebilirim:

• Bakım kolaylığı: Değişiklikler çoğunlukla tek katmanda yoğunlaşır.
• Test edilebilirlik: Katmanları ayrı ayrı birim testine tabi tutabilirsiniz.
• Teknoloji esnekliği: Veri ve sunum teknolojilerini daha rahat değiştirirsiniz.
• Ekip bölünmesi: Ön yüz ve arka uç ekipleri net sınırlarla çalışır.

Mesela web arayüzünü yenilemek istediğinizde, iş kuralları katmanına dokunmadan yeni bir sunum katmanı ekleyebilirsiniz. API ekibi, mobil uygulama için ayrı endpointler yazarken, aynı domain servisini kullanır. Böylece iş kuralları tek yerde toplanır ve kopya kod azalır.

Katmanlı mimari ayrıca risk yönetimi açısından da avantaj getirir. Veri tabanı tarafında büyük bir değişiklik yaptığınızda, etki alanını veri katmanıyla sınırlı tutabilirsiniz. Üst katmanlar sadece arayüz sözleşmesine bakar. Bu da dağıtım planlarını daha öngörülebilir kılar.

Endüstride uzun süredir kullanılan bu model, birçok ekip için ortak dil haline gelmiştir. Yeni bir geliştirici katıldığında, sunum katmanı, uygulama katmanı, repository gibi kavramları genellikle zaten bilir. Bu ortak sözlük, iletişim maliyetini düşürür ve kod incelemelerini hızlandırır.

Katmanlı mimarinin zorlukları

Avantajlarına rağmen katmanlı yaklaşımın ciddi tuzakları da vardır. En yaygın problem, her şeyi katmana uydurmaya çalışırken gereksiz soyutlama üretmektir. Küçük bir özellik için bile üç farklı projede değişiklik yapmak zorunda kalırsınız. Bu da özellikle hızlı iterasyon isteyen ürün ekiplerini zorlar.

Sık karşılaşılan zorlukları şöyle sıralayabilirim:

• Anemik domain modeli: Tüm iş kuralları servislerde toplanır, nesneler boş kalır.
• Katman atlama: Sunum katmanı doğrudan veri katmanına erişir.
• Aşırı DTO kullanımı: Basit akışlar gereksiz map işlemleriyle dolar.
• Yavaş değişim: Küçük bir kural için çok fazla dosya güncellenir.

Anemik model özellikle tehlikelidir. Domain nesneleri sadece property taşıyan çerçevelere dönüşür. Tüm davranış servis sınıflarına akar. Bu durumda katmanlı mimari varmış gibi görünür, ancak iş kuralları dağılmış bir halde yaşar. Sonunda kimsenin tam anlamıyla sahiplenmediği karmaşık bir kod tabanı ortaya çıkar.

Katman atlama da mimariyi içten içe çürütür. Bir geliştirici hızlı çözüm üretmek için sunum katmanından doğrudan repository çağırır. Kısa vadede iş çözüldüğü için kimse itiraz etmez. Fakat birkaç benzer kısayol sonrası, uygulama katmanı devre dışı kalır ve sınırlar bulanıklaşır.

Kendi ürünümüz YouContent360'ta bir iş kuralının hiçbir katmanda yaşamadığını gördük. Deneme hesabında makale sınırı 10'du. Ama sorguyu başlatan sunucu fonksiyonu, kaydı yazan repository ve arayüzdeki ekleme düğmesi, üçü de bu sınırı kontrol etmiyordu. Sonunda bir deneme hesabı 10 yerine 15 makale üretti. Kuralı tek bir yere, veritabanına eklenen bir tetikleyiciye taşıdık. Arayüzdeki kontrol yalnız kullanıcıya erken haber vermek için kaldı. Katmanlar vardı, ama kuralın sahibi yoktu.

Bu zorlukların çoğu, katmanlı mimariyi amaç değil, araç olarak gördüğünüzde azalır. Yani her yeni sınıf eklerken “Bu soyutlama gerçekten değer katıyor mu?” sorusunu sormak gerekir. Ayrıca ekip içinde kod örnekleri ve rehberler paylaşmak, ortak pratikleri netleştirir.

Katmanlı mimari ne zaman kullanılır?

Katmanlı mimariyi özellikle belirli tipte projelerde öneririm. Net iş kuralları olan, uzun süre yaşayacak, farklı istemcilerden erişilen sistemler bu yapıya uygundur. Söz gelimi, insan kaynakları, finans, envanter yönetimi gibi alanlarda bu mimari sağlam bir omurga sağlar.

Karar verirken şu adımları izlemek pratik olur:

1. İş kurallarının karmaşıklığını değerlendirin.
2. Ekip büyüklüğünü ve uzmanlık dağılımını analiz edin.
3. Dağıtım ve ölçek gereksinimlerini belirleyin.
4. Değişim hızını ve yol haritasını gözden geçirin.

Eğer sisteminizde iş kuralları zenginse, farklı kanallardan (web, mobil, entegrasyon API’leri) erişim varsa ve aynı domain uzun yıllar yaşayacaksa, katmanlı mimari güçlü bir seçenek olur. Böyle bir yapıda uygulama katmanı, domain kurallarını merkezde toplar ve istemciler için ortak bir kapı görevi görür.

Öte yandan çok küçük, tek amaçlı, kısa ömürlü bir servis için bu kadar ayrıntılı katman kurgulamak gereksiz yük yaratır. Basit bir API, tek bir proje içinde sade bir yapı ile daha okunabilir olabilir. Burada asıl kriter, mimari yatırımınızın geri dönüşüdür.

Mikroservis veya olay odaklı yaklaşımlar gündeme geldiğinde, katmanlı mimariyi tamamen bırakmak gerekmez. Her mikroservisin içinde, daha sade bir katmanlı yapı hâlâ işe yarar. Önemli olan, her serviste aynı şablonu körü körüne kopyalamak yerine, bağlama uygun seviyede katmanlandırma yapmaktır.

Genel bakış için katmanlı mimari ile mikroservis yaklaşımını kısaca karşılaştırmak faydalı olur.

Bu tabloyu, projenizin olgunluk seviyesine göre okumak önemli. Yeni başlayan bir ürün için tek bir katmanlı uygulama ile ilerlemek çoğu zaman daha mantıklıdır. Ürün büyüdükçe, bazı alanları ayrı servisler haline getirmek daha sağlıklı bir evrim sağlar.

Sık sorulan sorular

Katmanlı mimariyi bağımlılık yönünü tersine çeviren yaklaşımla karşılaştırmak için clean architecture nedir, anemik modelin karşılığı olan zengin domain modeli için domain-driven design nedir yazılarına; şirket ölçeğindeki teknoloji kararları için yazılım danışmanlığı sayfasına bakabilirsiniz.