Yazılım dünyasında bir “Clean Architecture” obsesyonu var ve karşıma sürekli çıkmaya başladı. Her röportajda, her kod incelemesinde, her teknik tartışmada mutlaka karşımıza çıkıyor: “Clean Architecture kullanıyor musunuz?” Sanki bunu kullanmayan kod pislik, karmaşık ve kötü yazılmış gibi algılanıyor.

Peki gerçekten öyle mi?

Sorun Nerede Başlıyor?

Clean Architecture’ın kendisi kötü bir konsept değil – Uncle Bob’un ortaya koyduğu prensipler mantıklı ve değerli. Ama sorun, bu yaklaşımın dogmatik bir şekilde her projeye, her duruma zorla uygulanmaya çalışılmasında.

Özellikle Flutter gibi frameworklerde bu durum komik boyutlara ulaşıyor. Flutter zaten kendi mimari felsefesine sahip, reactive ve widget tabanlı bir yapı sunuyor. Ama hayır, 5 ekranlı bir uygulama bile 7 katmanlı bir Clean Architecture’a ihtiyaç duyuyor artık!

Gerçek Maliyetler

1. Zaman Kaybı

Basit bir feature eklemek için:

• Entity tanımla
• Model tanımla (entity’den farklı olması lazım çünkü!)
• Repository interface’i yaz
• Repository implementation’ı yaz
• Use case yaz
• ViewModel/Cubit/Bloc’u yaz
• UI’ı bağla

Sonuç: 3 satırlık bir API çağrısı için 7 dosya, 200+ satır boilerplate kod.

2. Gereksiz Soyutlama

Çok uzak ihtimaller için katmanlara katman ekliyoruz. Her entity için ayrı model, her model için ayrı mapper, her işlem için ayrı use case…

Sonunda kod tabanının yarısı sadece bir katmandan diğerine veri taşıyan boilerplate kodlardan oluşuyor.

3. Okunabilirlik Kaybı

Kod akışını takip etmek için 5-6 dosya arasında zıplamak zorunda kalıyorsunuz. Yeni bir developer projeye katıldığında, basit bir login işleminin nasıl çalıştığını anlamak için saatlerce kod okumak zorunda kalıyor.

4. Over-Engineering

Her şey için interface, her şey için abstraction. Dependency Injection container’ları, service locator’lar, factory’ler…

Arkadaş, ben sadece bir liste göstermek istiyorum!

Flutter’da Durum Daha da Vahim

Flutter’ın kendi ekosistemi zaten çok güçlü:

• Provider/Riverpod ile state management
• dio ile network işlemleri
• Widget composition ile UI organizasyonu
• Built-in dependency injection

Bunlar yetmiyor mu? Neden üstüne bir de 3 katmanlı repository pattern ekliyoruz?

// Clean Architecture fanatiği yaklaşım:
class GetUserUseCase {
  final UserRepository repository;
  
  GetUserUseCase(this.repository);
  
  Future<Either<Failure, User>> call(String id) {
    return repository.getUser(id);
  }
}

// Pragmatik yaklaşım:
class UserService {
  Future<User> getUser(String id) async {
    return await dio.get('/users/$id');
  }
}

İkinci yaklaşımda ne kaybettik? Hiçbir şey. Ne kazandık? Zaman, basitlik, okunabilirlik.

“Ama Test Edilebilirlik…”

En çok duyduğumuz argüman bu. “Clean Architecture olmadan nasıl test edeceksin?”

Arkadaşlar, dependency injection için Clean Architecture’a ihtiyacınız yok! Flutter’da zaten mockito/mocktail var, get_it var, riverpod var. Basit bir service sınıfını mock’lamak için 5 katmanlı mimari kurmaya gerek yok.

Ne Zaman Kullanmalı?

Clean Architecture’ı red etmiyorum – doğru yerde kullanıldığında çok değerli:

• Büyük, karmaşık domainler: 50+ ekranlı enterprise uygulamalar
• Uzun ömürlü projeler: 10+ yıl maintenance beklenen sistemler
• Büyük takımlar: Farklı ekiplerin farklı katmanlarda çalıştığı durumlar
• Gerçekten karmaşık business rules: Finans, sağlık gibi ağır domain logic’i olan sektörler

Ne Zaman Gereksiz?

• MVP’ler ve prototype’lar
• Küçük-orta ölçekli uygulamalar (< 30 ekran)
• Basit CRUD işlemleri
• Tight deadline’lı projeler
• Küçük takımlar (2-5 kişi)

Pragmatik Alternatif

Flutter için önerim:

1. Feature-first organization: Her özelliği kendi klasöründe tutun
2. Services katmanı: API ve data işlemleri için
3. State management: Riverpod, Bloc veya Provider
4. Models: Sadece gerektiğinde DTO kullanın
5. Widgets: UI componentlerini mantıklı şekilde bölün

lib/
  features/
    auth/
      screens/
      widgets/
      auth_service.dart
      auth_provider.dart
    home/
      screens/
      widgets/
      home_service.dart
  shared/
    widgets/
    services/
    models/

Basit, anlaşılır, yeterli.

Sonuç

Clean Architecture bir araçtır, din değil. Her probleme uygun tek bir çözüm yoktur.

Proje büyüklüğüne, ekip yapısına, iş gereksinimlerine göre karar verin. Küçük bir proje için Clean Architecture dayatmak, çivi çakmak için şantiye vinci kullanmak gibidir – teknik olarak işe yarar ama hiç gerekli değildir.

En iyi mimari, ekibinizin anlayıp sürdürebileceği, projenizin ihtiyaçlarını karşılayan mimaridir.

Dogmalardan uzak durun, pragmatik olun. Kod yazmak için kod yazmayın.