Spring'in İçindeki Kalıplar — Strategy, Template Method, Proxy, Observer

Bir Spring Boot servisinde her gün en az dört tasarım kalıbı kullanıyorsun, çoğunu adını anmadan. Sorun kalıbı bilmemek değil. Sorun, çerçevenin onu nerede ve ne zaman çalıştırdığını bilmemek.

Strategy: yeni davranış, yeni bir sınıf

Strategy?Terimin tanımını açStrategyAynı işin farklı yapılış biçimlerini ayrı nesnelere taşıyan kalıp. Çağıran hangi stratejinin çalıştığını bilmez; yeni bir biçim yeni bir sınıftır.Sözlükte gör →, aynı işin farklı yapılış biçimlerini ayrı nesnelere taşır. Spring’de bunu kurmak için ayrı bir fabrika bile gerekmez:

1
public interface PaymentMethod {
2
    String key();                 // "card", "wallet", "bnpl"
3
    Receipt pay(Order order);
4
}
5

6
@Component class CardPayment   implements PaymentMethod { … }
7
@Component class WalletPayment implements PaymentMethod { … }
8

9
@Service
10
class Checkout {
11
    private final Map<String, PaymentMethod> methods;
12

13
    Checkout(List<PaymentMethod> all) {
14
        this.methods = all.stream().collect(toUnmodifiableMap(PaymentMethod::key, m -> m));
15
    }
16

17
    Receipt pay(Order order, String method) {
18
        return Optional.ofNullable(methods.get(method))
19
            .orElseThrow(() -> new UnsupportedPaymentMethod(method))
20
            .pay(order);
21
    }
22
}

Spring bu tipteki her bean’i listeye koyar. Yeni bir ödeme yöntemi yeni bir sınıftır; Checkout hiç değişmez.

Anahtarı key()’den almak bilinçli: Map<String, PaymentMethod> enjekte etseydin anahtar bean adı olurdu ve sınıfı yeniden adlandırmak API’yi sessizce değiştirirdi.

toUnmodifiableMap ise aynı anahtar iki kez gelirse uygulamanın açılmasını engeller.

Spring’in senin yerine yazdığı kalıplar

Template Method?Terimin tanımını açTemplate MethodBir işin değişmeyen iskeletini tek yerde tutup değişen adımları dışarıdan (alt sınıf ya da callback olarak) alan kalıp. Spring'de JdbcTemplate ve TransactionTemplate bunun örneği.Sözlükte gör → bir işin değişmeyen iskeletini tek yerde tutar. Değişen adımı sen verirsin:

@Transactional, @Cacheable ve @Async ise proxy?Terimin tanımını açproxySpring'in bean'in yerine koyduğu sarmalayıcı nesne. `@Transactional` gibi anotasyonlar burada çalışır — çağrı proxy'den geçmezse hiçbir şey olmaz.Sözlükte gör → kalıbıdır. Spring bean’ini bir sarmalayıcıyla değiştirir ve çağrı sarmalayıcıdan geçerken ek davranışı uygular.

Sınırı da buradan gelir: aynı sınıf içinden this. ile yapılan çağrı proxy’den geçmez. Ayrıntısı AOP ve self-invocation dersinde.

Satır satır: Observer ve transaction

Observer?Terimin tanımını açObserverBir olayı yayınlayanın, onu dinleyenleri tanımadan haber verdiği kalıp. Spring'de ApplicationEventPublisher ve @EventListener ile kurulur.Sözlükte gör → kalıbında yayıncı, onu kimin dinlediğini bilmez. Spring’de bu ApplicationEventPublisher ve @EventListener ile kurulur. Kolay görünür; ama dinleyici ne zaman çalışıyor?

Çözüm dinleyiciyi transaction’a bağlamak: @TransactionalEventListener. Varsayılan fazı AFTER_COMMIT’tir: dinleyici commit’i bekler, rollback olursa hiç çalışmaz.

Bir karar daha kalıyor: dinleyicinin hatası kime ulaşıyor? Senkron bir dinleyicinin istisnası yayıncıya döner. @Async onu başka bir thread’e taşır ve ana akışı korur.

Bankada bunun karşılığı transfer SMS’i. Kısa bir örnekte SMS’in yalnızca kesinleşen transferde gittiğini görelim.

1
public record TransferSent(TransferId transferId, String customerNo, Money amount, String maskedToIban) {}

1
@Service
2
class SendFastTransfer {
3

4
    private final Accounts accounts;
5
    private final Transfers transfers;
6
    private final FraudCheck fraud;
7
    private final ApplicationEventPublisher events;
8

9
    SendFastTransfer(Accounts accounts, Transfers transfers, FraudCheck fraud, ApplicationEventPublisher events) {
10
        this.accounts = accounts;
11
        this.transfers = transfers;
12
        this.fraud = fraud;
13
        this.events = events;
14
    }
15

16
    @Transactional
17
    public TransferId send(TransferRequest request) {
18
        Account source = accounts.lockByIban(request.fromIban());   // SELECT ... FOR UPDATE
19
        source.debit(request.amount());
20
        Transfer transfer = transfers.save(Transfer.pending(request));
21

22
        events.publishEvent(new TransferSent(
23
                transfer.id(), request.customerNo(), request.amount(), request.toIban().masked()));
24

25
        fraud.approveOrThrow(transfer);   // a fraud hold throws and rolls everything back
26
        return transfer.id();
27
    }
28
}

1
@Component
2
class TransferSmsListener {
3

4
    private final SmsGateway sms;
5

6
    TransferSmsListener(SmsGateway sms) {
7
        this.sms = sms;
8
    }
9

10
    // AFTER_COMMIT is the default phase: a rolled-back transfer never reaches this method.
11
    // @Async (enabled with @EnableAsync) keeps an SMS outage away from the transfer itself.
12
    @Async
13
    @TransactionalEventListener
14
    void on(TransferSent event) {
15
        sms.sendTransferNotice(event.customerNo(), event.amount(), event.maskedToIban());
16
    }
17
}

1
// Another way to write it: a plain listener.
2
@Component
3
class EarlyTransferSmsListener {
4

5
    private final SmsGateway sms;
6

7
    EarlyTransferSmsListener(SmsGateway sms) {
8
        this.sms = sms;
9
    }
10

11
    // Runs inside publishEvent: before the fraud check and before the commit.
12
    // If the fraud check then rolls the transfer back, this SMS has already gone out.
13
    @EventListener
14
    void on(TransferSent event) {
15
        sms.sendTransferNotice(event.customerNo(), event.amount(), event.maskedToIban());
16
    }
17
}

Kendin gör

Dinleyici anotasyonunu, @Async’i, ödemeyi ve mail sunucusunu değiştir. Üstte dinleyicinin kodu, altta iki thread’in zaman çizelgesi var.

1. Varsayılanla oynat. E-posta main thread’de, ödemeden önce gidiyor. Sonunda sipariş yok, e-posta var: hayalet e-posta.
2. Ödemeyi başarılı yap, mail sunucusunu düşür. Bu kez tersi oluyor: yan bir iş olan e-posta, sağlam siparişi geri alıyor.
3. @TransactionalEventListener’a geç. Ödeme reddedilince dinleyici hiç çalışmıyor. Ama mail sunucusu düşükken sipariş commit olduğu hâlde istemci hata görüyor.
4. @Async ekle. Sipariş kaydediliyor, istemci 201 alıyor, e-posta hatası ayrı thread’de loglanıyor. Dört görevi de tamamla.

Tuzaklar

Transaction olmadan @TransactionalEventListener. Olay @Transactional olmayan bir metottan yayınlanırsa dinleyici varsayılan olarak hiç çağrılmaz, ve bunu söyleyen bir hata da çıkmaz.

Bir refactor’da @Transactional kalkınca e-postalar sessizce kesilir. Gerekirse fallbackExecution = true ver.

AFTER_COMMIT içinde veritabanına yazmak. Asıl transaction zaten commit oldu; bu noktadaki yazma ona katılır ama bir daha commit edilmez. Kalıcı bir şey yazacaksan @Transactional(propagation = REQUIRES_NEW) kullan.

Commit ile gönderim arasındaki boşluk. AFTER_COMMIT’ten hemen sonra uygulama çökerse e-posta hiç gitmez. Kaybolmaması gereken olaylar için olayı siparişle aynı transaction’da bir tabloya yazıp sonradan gönderen bir yaklaşım (transactional outbox) gerekir.

Ana akışı olaylara gömmek. Siparişin tamamlanması için şart olan bir adım (stok düşmek gibi) olay dinleyicisine konursa akış kodda görünmez olur. Observer yan etkiler içindir; zorunlu adımlar doğrudan çağrı olarak kalmalı.

Kendini sına