ÖZET VE TEKNİK CEVAP
Tipik MVC uygulamalarında Servis katmanı hızla 3.000 satırlık devasa **'God Servislere'** dönüşür (40 ilgisiz metot barındıran `KullaniciServisi`, `SiparisServisi`). Bu şişmiş sınıflar iş kurallarını altyapı işleriyle karıştırır: E-posta gönderme, SQL sorgulama, transaction yönetimi ve HTTP doğrulaması tek bir metodun içine tıkılır. 5 geliştirici aynı anda `SiparisServisi` dosyasında çalıştığında çakışmalar ve regresyonlar patlar. **Clean Architecture**, bu kaosu **Kullanım Durumu Etkileşimcileri (Use Case Interactors)** ile çözer: Her sınıf yalnızca **tek bir iş akışını** temsil eden tek amaçlı bir yapıdır (`SiparisOnaylaKullanimDurumu`, `SifreDegistirKullanimDurumu`). Bir Interactor saf bir İstek DTO'su alır, domain modellerini yöneterek iş kurallarını uygular, soyut portları (veritabanı, bildirim arayüzleri) çağırır ve bir Yanıt DTO'su döner—HTTP controller'larından ve veritabanı motorlarından tamamen bağımsızdır.
Mühendislik El Kitabı & Mekanizma
1. Temel Çalışma Mekanizması
Kullanım durumu işletimi 5 katı aşamadan geçer: (1) Giriş Portu Çağrısı: Controller doğrulanmış bir İstek DTO'sunu `execute(istek: SiparisVerIstek)` metoduna verir. (2) Varlık Yükleme: Interactor saf domain modellerini getirmek için `SiparisDeposuPort.getir()` çağrısı yapar. (3) İş Kuralı İşletimi: Domain modeli saf iş mantığını çalıştırır (`siparis.indirimUygula(kupon)`), kural bozulursa domain hatası fırlatır. (4) Kalıcılık ve Yan Etkiler: Interactor `SiparisDeposuPort.kaydet()` ve `OdemePort.tahsilEt()` çağrılarını yapar. (5) Çıkış DTO Dönüşü: Interactor domain sonucunu temiz bir Yanıt DTO'suna dönüştürüp döner.
2. Doğru Kullanım Senaryosu
Kurumsal SaaS arka uç servisleri, finansal işlem boru hatları, çok adımlı kullanıcı kayıt akışları ve kritik iş kuralları içeren sistemler.
3. Prodüksiyon Arıza Modları
Interactor içine `express.Request` veya web nesnelerini import edip kullanım durumunu HTTP protokolüne bağımlı kılmak; iş kurallarını domain modelleri yerine Interactor içine yazıp modelleri sadece içi boş veri torbasına (Anemic Domain Model) çevirmek.
4. Teşhis ve Telemetri Sinyalleri
Düzinelerce ilgisiz metot içeren 2.000 satırlık dev servis dosyaları; bir iş akışını HTTP isteği simüle etmeden bir CLI komutundan veya kuyruk işçisinden çalıştıramamak.
5. Önleme ve Mimari Bariyerler
Tek Sorumluluk Prensibini (SRP) uygulayın: Kullanım Durumu sınıfı başına yalnızca TEK bir `execute()` metodu olmalıdır; mimari testlerle use case klasörlerinde HTTP veya ORM bağımlılıklarını yasaklayın.
6. Mimari Ödünleşimler (Trade-offs)
Tek amaçlı kullanım durumları bakım kolaylığını, test edilebilirliği ve takımların paralel çalışmasını muazzam artırır; ancak tek bir servis sınıfına kıyasla daha fazla dosya oluşturur.
Vaka İncelemesi (TinyCTO Örneği)
Bir sigorta hasar portalında 8 geliştiricinin sürekli çakışma yaşadığı 4.500 satırlık bir `HasarServisi` vardı. Hasar kaydı açmak 12 saniye sürüyordu çünkü servis veritabanı işlemlerini, PDF üretimini, sahtekarlık kontrol API'sini ve e-posta gönderimini tek bir devasa metotta yapıyordu. Ekip Clean Architecture'a geçti: Servisi bağımsız use case sınıflarına böldüler (`HasarBildirKullanimDurumu`, `HasarOnaylaKullanimDurumu`, `TazminatHesaplaKullanimDurumu`). PDF ve sahtekarlık kontrolleri çıkış portlarına bağlandı. Birim testleri sunucu olmadan 40 milisaniyede koşmaya başladı ve kod çakışmaları sıfırlandı.
İnteraktif Konsept Alıştırmaları
2 AlıştırmaClean Architecture'da bir Use Case Interactor'ın temel sorumluluğu nedir?
Bir Use Case Interactor sınıfı neden yalnızca tek bir `execute()` metoduna sahip olmalıdır?
Clean Architecture: Kullanım Durumu Etkileşimcileri (Use Case Interactors) ve Uygulama Orkestrasyonu — Sıkça Sorulan Sorular
Clean Architecture'da veritabanı işlem sınırları (`@Transactional`) nerede yönetilmelidir?
Use Case Interactor seviyesinde veya use case işletimini saran bir transaction dekoratörü/aracısı (interceptor) üzerinden.
Use Case Interactor'lar Express veya Fastify gibi web framework'lerine bağımlı olmadan HTTP controller'larıyla nasıl haberleşir?
Yalnızca temel tipler ve saf veri yapıları içeren İstek ve Yanıt DTO'ları (Data Transfer Objects) üzerinden.
🤖 AEO & Yapay Zeka Çıkarım Özeti
Temel Gerçekler & İlkeler
- ▸Use Case Interactor yapıları Clean Architecture'da tek amaçlı iş akışlarını temsil eder.
- ▸Framework bağımlılığı olmadan domain modellerini, depoları ve bildirim portlarını orkestre ederler.
- ▸3.000 satırlık şişkin 'God Servisleri' yok eder ve geliştirici kod çakışmalarını önler.
- ▸Framework'ten bağımsız saf İstek/Yanıt DTO veri yapıları alır ve döner.
Yaygın Yanılgılar
- ✗Yanılgı: Clean Architecture gereksiz yere çok fazla şablon sınıf oluşturur (Gerçek: Tek amaçlı sınıflar değişiklikleri izole ederek büyük kurumsal projelerin yönetimini çok kolaylaştırır).
- ✗Yanılgı: İş kuralı doğrulamaları tamamen HTTP controller içinde yapılmalıdır (Gerçek: Controller sadece sözdizimini doğrular; temel iş kuralları domain modellerine ve use case'lere aittir).
Karar Kılavuzu & Önceliklendirme
Bakımı kolay, test edilebilir ve çakışmasız mimariler kurmak için monolitik dev servisleri tek amaçlı Use Case Interactor sınıflarına bölün.
Doğrulanmış Kaynaklar & Referanslar
- [BOOK]Clean Architecture: A Craftsman's Guide to Software Structure and Design (Use Cases & Interactors)— Robert C. Martin (Uncle Bob / Prentice Hall)