Use Case Patterns

Use Case Pattern, uygulamanın iş senaryolarını framework, HTTP ve veritabanı detaylarından ayırarak modelleme yaklaşımıdır.

Amaç:

• İş kurallarını teknik detaylardan izole etmek
• Senaryo bazlı düşünmek
• Test edilebilirliği artırmak
• Karmaşıklığı yönetmek

Use Case, bir iş hedefini temsil eder.

“Login atmak” değil, “Kullanıcı Giriş Yapar” senaryosudur.

Use Case Nedir?

Use Case:

• Controller değildir
• Repository değildir
• Genel service değildir
• Tek bir iş senaryosunu temsil eder

HTTP (Express)
 ↓
Controller
 ↓
Use Case
 ↓
Repository (interface)
 ↓
DB (implementation)

Asıl iş mantığı Use Case içinde yer alır.

Service vs Use Case

Use Case yaklaşımı, “God Service” oluşmasını engeller.

Yapılmaması Gereken Hatalar

Use Case içinde:

• req, res kullanmak
• SQL query yazmak
• HTTP status döndürmek
• Birden fazla iş yapmak
• Farklı senaryoları birleştirmek

Use Case framework bağımsızdır.

Use Case Pattern Bileşenleri

1. Actor

Sistemle etkileşime giren kişi veya dış sistem.

Örnek:

• Customer
• Admin
• Bank API

2. System Boundary

Sistemin kapsadığı alan.

Ne bu sistemin sorumluluğunda? Ne değil?

Bu sınır net olmalıdır.

3. Use Case

Aktörün gerçekleştirmek istediği hedef.

Örnek:

• Place Order
• Withdraw Money
• Reset Password

Use Case Kalıpları

A. Inclusion Pattern (<<include>>)

Bir use case başka bir use case’i zorunlu olarak çağırır.

Örnek:

Place Order → Process Payment

Payment olmadan sipariş olmaz.

Amaç:

• Ortak adımları merkezi hale getirmek
• Tekrarlı kodu önlemek

B. Extension Pattern (<<extend>>)

Bir use case belirli koşullarda genişler.

Örnek:

Buy Product → Eğer kupon varsa → Apply Discount

Ana akış bozulmaz. Opsiyonel davranış eklenir.

C. Generalization Pattern

Bir use case’in farklı varyasyonları vardır.

Örnek:

Make Payment

• PayWithCard
• PayWithCash
• PayWithCrypto

Ana davranış korunur. Alt türler özelleştirir.

Mimari İç Yapı

Use Case genelde üç parçaya ayrılır:

1. Request Model

Input verisi.

HTTP’den gelen veri değil, normalize edilmiş input.

2. Interactor

Asıl iş mantığı.

• Validation
• Domain rule
• Orchestration

Interactor DB bilmez. Repository interface üzerinden çalışır.

3. Response Model

Dış dünyaya dönecek veri.

HTTP response değildir. Framework bağımsızdır.

Örnek: ATM Sistemi

Ana senaryo:

Withdraw Money

Include:

Verify PIN

Extend:

Eğer tutar limit üstündeyse → Extra Approval

Generalization:

Withdraw Money

• WithdrawByCard
• WithdrawByQR

Bu yapı sayesinde:

• Senaryo net
• Kurallar izole
• Test kolay

Use Case Pattern + Clean Architecture

Clean Architecture’da Use Case Application layer’dadır.

Domain
Application (Use Cases)
Infrastructure
Interface

Use Case:

• Domain’i kullanır
• Infrastructure’ı bilmez
• Controller’dan bağımsızdır

Ne Zaman Kullanılır?

• Karmaşık iş kuralları varsa
• Çok senaryolu sistem varsa
• Transaction orchestration gerekiyorsa
• Domain logic UI’dan izole edilmek isteniyorsa

Ne Zaman Gerekmez?

• Basit CRUD
• Tek tablo işlemleri
• İş kuralı yoksa

Her küçük endpoint için Use Case zorunlu değildir.