Clean Architecture: Kullanım Durumu Etkileşimcileri (Use Case Interactors) ve Uygulama Orkestrasyonu

Senior (L5)

⚡Ö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

6 Boyutlu Mimari Analiz

⚙️1. Temel Çalışma Mekanizması

Mekanizma

Kullanım durumu işletimi 5 katı aşamadan geçer:

Giriş Portu Çağrısı: Controller doğrulanmış bir İstek DTO'sunu execute(istek: SiparisVerIstek) metoduna verir.

Varlık Yükleme: Interactor saf domain modellerini getirmek için SiparisDeposuPort.getir() çağrısı yapar.

İş Kuralı İşletimi: Domain modeli saf iş mantığını çalıştırır (siparis.indirimUygula(kupon)), kural bozulursa domain hatası fırlatır.

Kalıcılık ve Yan Etkiler: Interactor SiparisDeposuPort.kaydet() ve OdemePort.tahsilEt() çağrılarını yapar.

Çı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

Kapsam

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ı

Kritik Risk

✓
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

Metrikler

✓
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

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)

Ödünleşim

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 Saha Örneği)

GERÇEK DÜNYA TELEMETRİSİ

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ırma

Clean Architecture'da bir Use Case Interactor'ın temel sorumluluğu nedir?

Tek bir iş akışını gerçekleştirmek için domain modelleri ile dış portlar arasındaki veri akışını ve iş mantığı işletimini koordine etmektir.

Bir Use Case Interactor sınıfı neden yalnızca tek bir `execute()` metoduna sahip olmalıdır?

Tek Sorumluluk Prensibini (SRP) katı bir şekilde korumak ve sınıfın bakılamaz bir 'Dev Nesneye' (God Object) dönüşmesini engellemek için.

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)