Spagetti Koda Son: Clean Architecture (Temiz Mimari) Nedir? Domain, Data ve Presentation Katmanları
Projeler büyüdükçe kodların çorba olmasını engelleyen efsanevi yazılım mimarisi: Clean Architecture. İş kurallarını (Business Logic) veritabanından, arayüzden ve kütüphanelerden bağımsız kılmanın kuralları ve katmanlı yapı rehberi.
Bir yazılım projesine ilk başlandığında her şey harikadır: Kodlar hızlı yazılır, özellikler peş peşe eklenir. Ancak 6 ay sonra proje büyüdüğünde korkunç bir durum ortaya çıkar: Veritabanındaki bir kolonun adını değiştirdiğinizde mobil arayüz çöker, arayüzdeki bir butonu kaldırdığınızda arka plandaki hesaplama patlar! Kodlar birbirine o kadar dolanmıştır ki, en ufak bir değişiklik bile haftalar süren test ve hata ayıklama gerektirir. Yazılım mühendisliğinde buna 'Spagetti Kod' veya 'Kod Çürümesi' denir. Robert C. Martin\'in (Uncle Bob) ortaya koyduğu 'Clean Architecture' (Temiz Mimari), işte bu çürümeyi sonsuza dek bitirmek için tasarlanmıştır.
Temel İlke: Bağımlılık Kuralı (The Dependency Rule):
Clean Architecture\'ın kalbinde tek bir sarsılmaz kural yatar: 'İç katmanlar dış katmanlar hakkında hiçbir şey bilmez; bağımlılık oku daima dıştan içe doğru akar.' Yani sizin çekirdek iş mantığınız (Domain), veritabanınızın MySQL mi yoksa MongoDB mi olduğunu BİLMEMELİDİR. Hatta arayüzünüzün bir Android ekranı mı, web sayfası mı yoksa terminal komutu mu olduğunu bile bilmemelidir! Dışarıdaki teknolojiler (framework\'ler, veritabanları, UI) sadece birer detaydır ve istenildiği zaman iş mantığına dokunulmadan değiştirilebilmelidir.
Temiz Mimarinin 3 Temel Katmanı:
1. Domain Katmanı (En İçteki Çekirdek): Uygulamanızın kalbidir. Varlıklar (Entities) ve Kullanım Senaryoları (Use Cases) burada yer alır. Örneğin: 'Bir kullanıcı sepet tutarı 500 TL üzerindeyse %10 indirim kazanır.' Bu kural ne Android\'e, ne React\'e ne de SQL\'e bağlıdır; saf bir iş kuralıdır. Bu katmanda hiçbir harici kütüphane veya veritabanı import\'u bulunmaz.
2. Data / Infrastructure Katmanı (Veri Sağlayıcı): Veritabanı sorguları, API çağrıları, dosya okuma işlemleri ve ağ iletişimleri bu katmandadır. Domain katmanındaki soyut arayüzleri (Interface/Repository) burada somutlaştırır.
3. Presentation Katmanı (Arayüz & Sunum): Kullanıcının gördüğü ekrandır (Android Activity/Compose, React bileşenleri, CLI çıktısı). Sadece kullanıcıdan gelen girdiyi alır, ilgili Use Case\'e iletir ve sonucu ekrana çizer.
Repository Deseni ve Arayüz Ayrımı (Inversion of Control):
Peki Domain katmanı veritabanını bilmiyorsa veriyi nasıl kaydeder? İşte burada nesne yönelimli programlamanın büyüsü devreye girer: Domain katmanında sadece bir sözleşme (Interface) tanımlarsınız: interface OgrenciDeposu { fun getir(id: Int): Ogrenci }. Domain sadece bu arayüze güvenir. Data katmanı ise gider bu arayüzü SQL ile veya Firebase ile doldurur. Yarın bir gün MySQL\'den vazgeçip PostgreSQL\'e geçmek isterseniz Domain katmanındaki tek bir satır koda bile dokunmazsınız; sadece Data katmanındaki sınıfı değiştirirsiniz!
Test Edilebilirlik ve Bakım Kolaylığı:
Clean Architecture\'ın en büyük ödülü birim testlerdir (Unit Testing). İş mantığınız veritabanına veya arayüze bağımlı olmadığı için, veritabanı sunucusu açık olmadan veya bir Android emülatörü çalıştırmadan çekirdek kurallarınızı milisaniyeler içinde test edebilirsiniz. Mock (sahte) depolarla tüm senaryoları simüle etmek çocuk oyuncağıdır.
Sonuç: Ne Zaman Clean Architecture Uygulanmalı?:
Clean Architecture her küçük 2 günlük hobi projesine körü körüne uygulanmamalıdır; çünkü katmanlar, modeller arası dönüştürücüler (mappers) ve arayüzler ilk başta fazladan dosya ve şablon kod (boilerplate) gerektirir. Ancak; uzun vadeli, büyümesi hedeflenen, birden fazla geliştiricinin çalıştığı veya zamanla arayüzü ve veritabanı değişebilecek profesyonel sistemlerde Clean Architecture, projenin yıllar sonra bile tıkır tıkır yaşamasını sağlayan en güçlü mühendislik omurgasıdır.