1. GİRİŞ

Layered Architecture (Katmanlı Mimari) yazılım geliştirmede uzun yıllardır kullanılan, kavramsal olarak sadeliği ve uygulama organizasyonuna getirdiği net sınırlarla bilinen bir yaklaşımdır. Temelde sistem fonksiyonlarını sorumluluklarına göre ayırarak her katmanın belirli görevleri üstlenmesini sağlar: sunum (presentation), uygulama (application), domain / iş mantığı ve veri erişim (data access) gibi. Bu makale, katmanlı mimarinin neden hâlâ konuşulduğunu, hangi durumlarda tercih edilmesi gerektiğini, teknik iç işleyişini, avantajlarını, sınırlamalarını ve pratikte nasıl uygulanacağını mühendis bakış açısıyla ele alır.

Bu teknoloji neden konuşuluyor?

• Kurumsal uygulamalar hâlâ katmanlı anlayışla tasarlanıyor; birçok eğitim ve framework bunu temel alıyor.
• Basitliği ve anlaşılabilirliği nedeniyle ekiplerin hızlı adapte olmasını sağlıyor.
• Mikroservislere veya daha sofistike mimarilere geçiş aşamasında katmanlı yapı iyi bir geçiş adımı sunuyor.

Kimler için önemli?

• Yazılım mimarları ve teknik liderler
• Kurumsal backend geliştiriciler
• Proje yöneticileri ve teknik ekipler — özellikle maintainability (sürdürülebilirlik) öncelikli projeler

Hangi problemleri çözüyor?

• Kod organizasyonu ve sorumluluk ayrımı
• Test edilebilirlik ve modüler geliştirilebilirlik
• Takımlar arası iş bölümü ve bağımsız geliştirme kolaylığı

2. KAVRAMSAL TEMELLER

2.1 Layered Architecture nedir?

Katmanlı mimari, uygulamanın işlevlerini birkaç mantıksal katmana ayırır. Her katman yalnızca daha içteki (veya daha genel) katmana bağımlıdır; bu bağımlılık hiyerarşisi mimarinin temelini oluşturur. Genel olarak kabul görmüş katmanlar şunlardır:

• Presentation / UI: Kullanıcıya gösterim, istemci isteklerini alıp doğrulama.
• Application / Service: Uygulama akışını koordine eder; use‑case seviyesinde mantığı yönetir.
• Domain / Business Logic: İş kuralları, domain modeller ve doğrulamalar burada yer alır.
• Data Access / Infrastructure: Veritabanı, dış servisler, messaging gibi dış kaynaklara erişim implementasyonları.

2.2 Terminoloji ve bileşenler

• Controller / Presenter: Presentation katmanının elemanlarıdır; istekleri parse eder, response oluşturur.
• Service / Use Case: Application katmanında iş akışını koordine eden fonksiyonlardır.
• Entity / Value Object: Domain nesneleri; iş kurallarına ait davranışları taşır.
• Repository / DAO: Veri erişim arabirimleri; domain bağımsız arayüzlerle tanımlanır, implementasyonlar infra tarafında yer alır.

3. NASIL ÇALIŞIR? — TEKNİK MİMARİ VE AKIŞ

3.1 Sistem mimarisi — katman ilişkisi

Katmanlı mimaride veri akışı tipik olarak sunumdan başlayıp veri erişim katmanına kadar ilerler ve sonuç ters yönde döner. Önemli prensip, her katmanın yalnızca bir altındaki katmana doğrudan bağlı olmasıdır (veya arayüz üzerinden dolaylı). Bu, coupling'i azaltır ve bir katmanın içindeki değişikliklerin diğer katmanlara yayılmasını sınırlar.

3.2 Tipik istek akışı

1. Client (browser/mobile) HTTP isteği gönderir — Presentation katmanı (Controller) alır.
2. Controller isteği validasyon için Application katmanına iletir; Use Case/Service çağrılır.
3. Service domain modellerini (Entity) kullanarak iş kurallarını uygular; gerektiğinde Repository çağırarak veri okur/yazar.
4. Repository implementasyonu Data Access katmanında çalışır ve veritabanı ile etkileşir.
5. Sonuç geriye doğru döner; Controller response oluşturur ve client'a gönderir.

3.3 Soyutlama ve arayüzler

Katmanlı mimarinin gerçeğe dönüştürülmesi için arayüz tabanlı soyutlamalar kullanılır. Domain ve Application katmanları genellikle Data Access katmanına bir arayüz (IRepository) üzerinden bağımlılık verir; concrete implementasyonlar infra katmanında yer alır. Bu, testlerde mock kullanımı ve modül izolasyonuna imkan sağlar.

3.4 Transaction boundary ve error handling

Transaction yönetimi genellikle Application katmanında veya Repository seviyesinde belirlenir. Uzun süreli işler veya distributed transaction gerektiren senaryolarda saga pattern veya eventual consistency tercih edilir. Hata yönetimi ise her katmanda kendi sorumluluklarına göre ele alınmalı; presentation katmanı user‑friendly mesaj üretirken domain hata sınıfları iş mantığını korumalıdır.

4. GERÇEK DÜNYA KULLANIMLARI

4.1 Kurumsal web uygulamaları

Bankacılık, sigorta, ERP ve CRM gibi kurumsal uygulamalarda katmanlı mimari yaygındır. Bu alanlarda domain mantığının net ayrılması, uyumluluk ve reglasyon gereksinimleri için önemlidir. Örneğin bir bankacılık uygulamasında; presentation (internet bankacılığı), application (transfer senaryoları), domain (hesap, bakiye kuralları) ve data access (transactional DB) katmanları birbirinden ayrılmıştır.

4.2 Büyük e‑ticaret platformları

E‑ticaret uygulamaları başlangıçta monolitik katmanlı mimariyle geliştirilebilir; katalog, sipariş, ödeme gibi modüller her biri kendi katmanlarında organize edilir. Büyüme ve skalasyon ihtiyacı doğduğunda bu katmanlı yapı mikroservislere veya domain odaklı yapılara evrilebilir.

4.3 API‑first ve entegrasyon odaklı uygulamalar

API tabanlı servisler için katmanlı yapı, API controller'ların presentation, servislerin orchestration ve repository'lerin persistence sorumluluklarını netleştirir. Bu model entegrasyonların yönetilmesini kolaylaştırır ve API versioning stratejilerine yeterli altyapı sağlar.

5. AVANTAJLAR VE SINIRLAMALAR

Avantajlar

• Basitlik ve anlaşılabilirlik: Katmanların rolleri net olduğundan yeni geliştiriciler yapıyı hızlıca kavrar.
• Modülerlik: Her katman ayrı test edilebilir; mock/ stub kullanımı kolaydır.
• Bakım kolaylığı: Değişiklikler genellikle belirli bir katmana izole edilebilir.
• Ekip organizasyonu: Takımlar farklı katmanlarda uzmanlaşabilir ve paralel çalışabilir.

Sınırlamalar

• Over‑engineering riski: Küçük projeler için katmanlı yapı gereksiz karmaşıklık getirebilir.
• Performans yükü: Fazla katman arası mapping ve DTO dönüşümleri maliyet yaratabilir.
• Tight layering hataları: Katman kurallarının ihlali (ör. UI doğrudan DB'ye erişmesi) mimari bozulmalara yol açar.
• Scaling sınırlamaları: Monolitik katmanlı uygulamalar yatayda ölçeklenirken mikroservisler kadar esnek olmayabilir; refactor maliyeti yüksek olabilir.

6. ALTERNATİFLER VE KARŞILAŞTIRMA

7. EN İYİ PRATİKLER

Production kullanımı

• Basit projelerde gereksiz katmanlılık yapmayın; ihtiyaç odaklı yaklaşın.
• Katman kurallarını (dependency direction) kod incelemelerinde zorunlu kılın.
• Interface tabanlı repository ve servis soyutlamaları kullanın; implementasyonları infra katmanına yönlendirin.

Performans optimizasyonu

• Mapping ve DTO dönüşümlerini minimize edin; ağır veri dönüşümleri için streaming veya pagination kullanın.
• Hot path'lerde cache, read‑replica veya CQRS gibi pattern'leri değerlendirin.

Güvenlik

• Authentication/Authorization katmanını presentation veya gateway katmanına koyun; domain yalnızca yetki bilgisini kullanarak karar versin.
• Input validation'ı hem transport‑level hem domain‑level'da uygulayın.

Observability

• Katmanlar arası latency, hata oranları, DB sorgu süreleri ve mapping maliyetlerini ölçün.
• Correlation ID ile uçtan uca izleme sağlayın; log seviyelerini katmanlara göre ayarlayın.

8. SIK YAPILAN HATALAR

• Katman talimatlarını ihlal etmek: Presentation katmanından doğrudan Database çağrıları yapmak.
• Servis katmanını tamamen pasif hale getirip domain logic'i controller içinde uygulamak.
• Çok sayıda küçük katman yaratarak yönetimsel karmaşa oluşturmak.
• Test stratejisini katmanlara göre ayarlamamak — unit, integration ve end‑to‑end testleri karıştırmak.

9. GELECEK TRENDLER

1. Layered + Cloud Native: Katmanlı tasarımın cloud native yaklaşımlarla (serverless, managed services) uyumlu uygulanması artacak.
2. Tooling & AI: Kod analiziyle architectural smell tespit eden ve katman ihlallerini gösteren araçlar, AI‑destekli refactor önerileri yaygınlaşacak.
3. Hybrid mimariler: Layered mimariler, gerekli yerlerde hexagonal veya clean pattern'leri ile harmanlanacak; monolitten microservice'e geçişte hibrit yaklaşımlar öne çıkacak.

EK BÖLÜMLER

Sık Sorulan Sorular (FAQ)

1. 1. Layered Architecture her projeye uygun mu?

   Hayır. Küçük veya kısa ömürlü projelerde basitlik adına düz bir yapı daha uygun olabilir. Ancak sürdürülebilirlik ve ekip büyümesi beklenen projeler için iyi bir başlangıçtır.

2. 2. Katman sayısı kaç olmalı?

   Genelde 3–4 temel katman (Presentation, Application, Domain, Data) yeterlidir. İhtiyaca göre alt katmanlar eklenebilir ama fazla bölme yönetimi zorlaştırır.

3. 3. Katmanlı mimari performansı yavaşlatır mı?

   Doğrudan bir yavaşlama değil; ancak fazla dönüşüm ve mapping opsiyonları CPU ve bellek maliyeti getirebilir. Hot path'lerde optimizasyon ve caching ile dengelemek gerekir.

4. 4. Monolitik katmanlı yapıdan microservice'e nasıl geçilir?

   Strangler Fig pattern ile küçük parçalar çıkarılarak, bounded context'ler belirlenip bağımsız servisler halinde taşınır. Önce domain boundary'leri netleştirmek önemlidir.

5. 5. Layered ile CQRS/ES uyumlu mu?

   Evet. Read ve write yollarını ayırmak (CQRS) katmanlı mimari içinde uygulanabilir; event sourcing (ES) paylaşımlı infra ve uygulama katmanları ile entegre edilebilir.

6. 6. Hangi metrikleri izlemeliyim?

   Katman bazlı latency, mapping/serialization maliyetleri, DB query süreleri, hata oranları ve test coverage önemli metriklerdir.

7. 7. Katman ihlallerini nasıl önlerim?

   Kod incelemeleri, static analysis kuralları ve CI kontrolleri ile katman ihlallerini tespit edip önleyebilirsiniz. Interface'ler ve paket boundary'leri teknik olarak zorlanabilir.

8. 8. Layered Architecture için önerilen teknolojiler nelerdir?

   .NET, Java ve Spring ekosistemleri katmanlı mimariyi doğal olarak destekler. Önemli olan framework değil; doğru soyutlamalar ve katman disiplinidir.

Anahtar Kavramlar

Presentation

Kullanıcı arayüzü veya API endpoint'lerinin bulunduğu katman.

Application / Service

Use case'leri koordine eden ve transaction boundary'lerini yöneten katman.

Domain

İş kuralları ve domain modellerinin yer aldığı katman.

Data Access

Veritabanı, cache ve dış servislerle etkileşimi sağlayan katman.

Strangler Fig

Legacy sistemleri yeni mimariye kademeli taşıma stratejisi.

Öğrenme Yol Haritası

1. 0–1 ay: Katmanlı mimari temel kavramlarını ve SOLID prensiplerini öğrenin; küçük bir CRUD uygulaması tasarlayın.
2. 1–3 ay: Arayüz tabanlı soyutlamalar, repository pattern ve servis katmanı uygulamaları yapın; unit testler ekleyin.
3. 3–6 ay: Strangler Fig ile legacy parçalara müdahale, CQRS ve caching stratejileri üzerine pratikler yapın.
4. 6–12 ay: Cloud native adaptasyon, observability, performance tuning ve microservice'e geçiş pratikleri üzerinde çalışın.