N-Tier Architecture Nedir? Nerede Kullanılır?

N-Tier Architecture, uygulamanın fiziksel deployment bölümlerini ve aralarındaki iletişimi düzenler. Layer ise kodun mantıksal sorumluluk sınırıdır. Bu ayrım, klasör sayısını deployment veya scaling kabiliyetiyle karıştırmamak için önemlidir.

1. N-Tier Architecture Nedir?

N-Tier Architecture, uygulamanın mantıksal layer ve fiziksel tier sınırlarıyla düzenlendiği bir mimari modeldir. Her katman, belirli bir görevi veya sorumluluk grubunu üstlenir ve diğer katmanlarla yalnızca belirlenmiş arabirimlerle iletişim kurar.

Temel Katmanlar

• Presentation (Sunum) Katmanı
• Business Logic (İş Katmanı)
• Data Access (Veri Erişim) Katmanı
• (Opsiyonel: Service, Integration, Caching, API vb.)

N: Fiziksel tier sayısıdır; her logical layer için ayrı sunucu gerekmez. Geleneksel web, application ve database tier örneğinde Data Access kodu application tier içinde yer alır.

2. Katmanların Ayrıntılı Açıklamaları

2.1 Presentation Layer (Sunum Katmanı)

• Kullanıcı ile etkileşim sağlar (Web arayüzü, mobil uygulama, desktop app).
• Giriş doğrulama, kullanıcı deneyimi, veri gösterimi burada.
• Doğrudan veri erişim veya iş kurallarına müdahale etmez.

Pratik Örnek:
Web API controller, ASP.NET MVC View, Blazor UI

2.2 Business Logic Layer (İş Katmanı)

• İş kuralları, karar mekanizmaları, uygulama içi mantık burada.
• Bu layer, veriyi işleyen business kuralını ve invariant’ları uygular.
• Uygulamanın belirlediği contract’lar üzerinden veri erişimi ve dış servislerle çalışır; yalnız iki katmanla sınırlı değildir.

Pratik Örnek:
Kullanıcı kaydındaki business kuralı burada yer alır. Ancak password hashing için doğrulanmış identity API’si, eş zamanlı kayıt için database uniqueness constraint gerekir.

2.3 Data Access Layer (Veri Erişim Katmanı)

• Veritabanı ile uygulama arasındaki köprüdür.
• Sorgular, ekleme/güncelleme/silme işlemleri burada tanımlanır.
• Doğrudan kullanıcı veya UI ile temas etmez.

Pratik Örnek:
Entity Framework repository, Dapper query, SQL bağlantı kodları

2.4 Opsiyonel Ek Katmanlar

• Service Layer: Dış API ile entegrasyon, ortak servisler (ör: SMS, Mail).
• Caching Layer: Sık erişilen veriler için performans önbelleği.
• Integration Layer: Harici sistemlerle veri alışverişi.
• API Gateway Layer: Client trafiğini birden çok servise yönlendirme ihtiyacını karşılar; her uygulama gateway gerektirmez.

4. N-Tier ve Layered Architecture Arasındaki Fark

• Layered Architecture: Katmanlar mantıksal; fiziksel dağılım şart değildir.
• N-Tier Architecture: Tier, fiziksel deployment sınırıdır. Ancak birkaç logical layer aynı tier’da yer alır; her layer için ayrı process açmayın.

5. Tipik Bir 3-Tier Mimari Diyagramı

1. Presentation
   Kullanıcı arayüzü (Web, Mobil, Masaüstü)
2. Business Logic
   Servisler, kurallar, uygulama içi süreçler
3. Data Access
   Veritabanı bağlantıları, ORM’ler

6. C# ile Katman Yapısı Kod Örneği

Entity Katmanı

public class Product
{
    public int Id { get; set; }
    public string Name { get; set; }
}

Data Access Katmanı

public interface IProductRepository
{
    Product GetById(int id);
    void Add(Product product);
}

Business Logic Katmanı

public class ProductService
{
    private readonly IProductRepository _repository;

    public ProductService(IProductRepository repository)
    {
        _repository = repository;
    }

    public void RegisterProduct(Product product)
    {
        // İş kuralları
        if (product == null)
            throw new ArgumentNullException(nameof(product));
        if (string.IsNullOrWhiteSpace(product.Name))
            throw new ArgumentException("Ürün adı zorunludur.");
        _repository.Add(product);
    }
}

Presentation Katmanı (ör. Web API Controller)

[ApiController]
[Route("api/products")]
public class ProductsController : ControllerBase
{
    private readonly ProductService _service;

    public ProductsController(ProductService service)
    {
        _service = service;
    }

    [HttpPost]
    public IActionResult Create(Product product)
    {
        _service.RegisterProduct(product);
        return Ok();
    }
}

N-Tier Architecture avantajları

• Modülerlik: Ekipler belirli sorumlulukta çalışır; ancak ortak contract değişikliği koordinasyon gerektirir.
• Test Edilebilirlik: İzole business davranışını unit test, altyapı sözleşmesini integration test ile doğrulayın.
• Bakım Kolaylığı: Contract aynı kalırsa bazı değişiklikleri izole edebilirsiniz; shared model veya davranış değişimi consumer’ları etkiler.
• Güvenlik: Permission, network isolation ve API policy ile erişim sınırlarını uygularsınız; layer adı güvenlik kontrolü değildir.
• Yeniden Kullanılabilirlik: Contract ve domain anlamı uyuyorsa implementasyonu paylaşın; yalnız benzer class adları yeterli değildir.

N-Tier Architecture maliyetleri

• Başlangıç Karmaşıklığı: Küçük projeler için gereksiz karmaşa ve “over engineering” riski.
• Katmanlar arası bağımlılık: Yanlış uygulamada, üst katmanlar alttakilere sıkıca bağlanabilir.
• Performans: Her katmanda veri taşımak ek yük getirebilir (özellikle çok katmanlı ve network ayrımı varsa).
• Fazla soyutlama: Anlaşılırlığı düşürebilir, yeni başlayanlar için takip zorlaşabilir.

9. N-Tier Mimarinin Gerçek Kullanım Senaryoları

• Kurumsal ERP Sistemleri
  Büyük ölçekli, çok kullanıcılı ve modüler yapı gerektiren uygulamalarda (örn: SAP, Oracle).
• Bankacılık ve Finans
  Yetki, işlem bütünlüğü ve entegrasyon sorumluluklarının ayrımı gerekir; fiziksel topology’yi gereksinime göre seçin.
• E-ticaret Siteleri
  Sipariş, stok ve ödeme farklı business modülleridir; her modül kendi presentation/business/data erişim ayrımını içerebilir. Modül ile layer aynı eksen değildir.
• Kamu ve Sağlık Uygulamaları
  Veri gizliliği ve bağımsız bakım gerektiren projelerde.

10. Katmanlar Arası Bağımlılıklar ve Tasarım Önerileri

• Closed-layer tasarımında yalnız bitişik alt layer’a erişin. Open-layer tasarımı daha aşağıdaki layer’a doğrudan erişime izin verir; seçimi explicit yapın.
• Interface, değişen implementasyon veya test sınırı varsa faydalıdır; her delegation method için yeni abstraction gerekmez.
• Değişen altyapı bağımlılığını composition root üzerinden verin; DI container gereksinimini uygulama ölçeğine göre seçin.
• DTO, Entity ve ViewModel rollerini açık tutun. Ancak aynı model shape’i için her layer’da bire bir kopya ve gereksiz mapping üretmeyin.

11. Genişletilmiş (4+, 5+ Katman) Mimari Senaryolar

• Service Layer: Microservice veya entegrasyon odaklı projelerde.
• Caching Layer: Performans gerektiren uygulamalarda (örn: Redis, Memcached).
• API Gateway Layer: Birden fazla API’ye sahip sistemlerde.
• Reporting Layer: Büyük veri, analitik ve raporlama gerektiren projelerde.

12. Sık Yapılan Hatalar

• Katman sınırlarının “ihlal edilmesi” (ör: UI’dan doğrudan veritabanına erişmek)
• İş kurallarını Data Access veya UI katmanında tutmak
• Kod tekrarları ve katmanlar arası veri modeli karışıklığı
• Fazla soyutlama ve gereksiz interface furyası
• Business kodunda değişen altyapı bağımlılığını gizlemek; composition root’taki bilinçli nesne oluşturmayı hata saymayın

Microservices ile N-Tier aynı karar değildir; bir servisin içi de layered olabilir. Business kurallarını unit test, query ve persistence davranışını gerçek provider ile integration test üzerinden doğrulayın. Ayrıca her delegation’ı ayrı layer’da tekrar test etmek yerine riskli sınırı test edin.

N-Tier, Monolith ve Microservices farklı eksenlerdir

16. Kaynaklar

• Microsoft Docs: N-Tier Architecture
• Microsoft Docs: N-tier .NET Framework data applications overview
• Patterns of Enterprise Application Architecture – Martin Fowler
• The Clean Code Blog-The Clean Architecture
  

C# örnekleri logical layer ayrımını gösterir; ayrı process veya network tier implementasyonu değildir. Repository implementasyonu, DI registration ve ASP.NET Core exception/HTTP mapping’i uygulamanın sağlaması gerekir. Ayrıca DTO ve Entity sınırı için DTO ViewModel Entity incelemesine bakın.