Blog

Yazılım projelerinin büyümesiyle birlikte kod tabanının yönetilebilirliği kritik bir sorun hâline gelir. Robert C. Martin (Uncle Bob) tarafından önerilen Clean Architecture, bu soruna sistematik bir çözüm sunar. BUZ Yazılım olarak 19 yılı aşkın deneyimimizde bu prensipleri aktif olarak uyguluyoruz.

Clean Architecture Nedir?

Clean Architecture, yazılım sistemlerini bağımsız, test edilebilir ve sürdürülebilir katmanlara ayıran bir mimari yaklaşımdır. Temel felsefesi:

• Çerçeve bağımsızlığı: Mimari belirli bir framework'e bağlı değildir
• Test edilebilirlik: İş kuralları UI, veritabanı veya harici servisler olmadan test edilebilir
• UI bağımsızlığı: Kullanıcı arayüzü, iş mantığını etkilemeden değişebilir
• Veritabanı bağımsızlığı: Veritabanı değiştirilebilir
• Harici servis bağımsızlığı: Dış dünyadan izole iş kuralları

Clean Architecture'ın özü basittir: bağımlılıklar her zaman dıştan içe doğru yönelmelidir. İç katmanlar, dış katmanlar hakkında hiçbir şey bilmemelidir.

Katman Yapısı

Clean Architecture, eşmerkezli daireler şeklinde dört ana katmandan oluşur:

1. Entities (Varlıklar) — En İç Katman

• İş kurallarını kapsülleyen temel nesneler
• Uygulamadan bağımsız, evrensel iş mantığı
• En az değişen katman
• Hiçbir dış bağımlılığı yoktur

2. Use Cases (Kullanım Senaryoları)

• Uygulamaya özgü iş kuralları
• Entities'i orkestre eden iş akışları
• Girdi ve çıktı portlarını tanımlar
• Her use case tek bir sorumluluğa sahiptir

3. Interface Adapters (Arayüz Adaptörleri)

• Controllers: Gelen istekleri use case formatına dönüştürür
• Presenters: Use case çıktılarını UI formatına çevirir
• Gateways: Veritabanı erişim katmanı
• Mappers: Veri dönüşüm nesneleri

4. Frameworks & Drivers (Çerçeveler) — En Dış Katman

• Web framework'leri, veritabanı sürücüleri
• UI bileşenleri
• Harici servis istemcileri
• İnfrastructure detayları

Bağımlılık Kuralı (Dependency Rule)

Clean Architecture'ın en önemli kuralı:

• Kaynak kod bağımlılıkları yalnızca içe doğru yönelir
• İç katmanlar dış katmanları bilmez
• Dış katman değişiklikleri iç katmanları etkilemez
• Bağımlılık tersine çevirme (Dependency Inversion) prensibi uygulanır

Pratik Örnek

// Domain katmanı — interface tanımı
public interface IOrderRepository
{
    Task<Order> GetByIdAsync(int id);
    Task SaveAsync(Order order);
}

// Infrastructure katmanı — implementasyon
public class SqlOrderRepository : IOrderRepository
{
    // Veritabanı erişim detayları burada
}

Domain katmanı, SQL veritabanı hakkında hiçbir şey bilmez. Sadece interface'i tanımlar.

SOLID Prensipleriyle İlişkisi

Clean Architecture, SOLID prensiplerinin doğal bir uzantısıdır:

Single Responsibility (Tek Sorumluluk)

• Her katman tek bir sorumluluğa sahiptir
• Use case'ler tek bir iş akışını temsil eder

Open/Closed (Açık/Kapalı)

• Yeni özellikler ekleme, mevcut kodu değiştirmeden yapılabilir
• Plugin mimarisi ile genişletilebilirlik

Liskov Substitution (Liskov Yerine Geçme)

• Interface'ler üzerinden çalışma, implementasyonları değiştirilebilir kılar

Interface Segregation (Arayüz Ayırma)

• Küçük, odaklı interface'ler tanımlama
• İstemcilerin ihtiyaç duymadığı metotlara bağımlılık yaratmama

Dependency Inversion (Bağımlılık Tersine Çevirme)

• Üst seviye modüller alt seviye modüllere bağlı değildir
• Her ikisi de soyutlamalara bağlıdır

Uygulama Önerileri

Proje Yapısı

Solution/
├── Domain/                 # Entities + Use Case Interfaces
├── Application/            # Use Cases Implementation
├── Infrastructure/         # Veritabanı, E-posta, Dosya sistemi
├── WebAPI/                 # Controllers, Middleware
└── Tests/                  # Birim ve Entegrasyon Testleri

Yaygın Hatalar

1. Aşırı mühendislik: Her proje için Clean Architecture gerekmez
2. Katman ihlalleri: Bağımlılık kuralına uymayan kısa yollar
3. Anemic domain model: İş mantığını servislere taşıyıp entities'i boş bırakma
4. Mapping cehenemi: Katmanlar arası aşırı nesne dönüşümü

Ne Zaman Kullanmalı?

• Orta-büyük ölçekli projeler
• Uzun ömürlü olması beklenen sistemler
• Birden fazla geliştiricinin çalıştığı projeler
• Yüksek test kapsamı gerektiren uygulamalar

Sonuç

Clean Architecture, başlangıçta ek karmaşıklık gibi görünse de uzun vadede büyük ölçekli projelerde bakım kolaylığı, test edilebilirlik ve esneklik sağlar. BUZ Yazılım olarak, müşterilerimizin ihtiyaçlarına uygun mimari çözümler sunuyoruz. Projeniz için doğru mimari yaklaşımı belirlemek için bizimle iletişime geçin.