Spring AOP

3.1 AOP nedir?

AOP, business kodun içine tekrar tekrar yazmak istemediğimiz ortak davranışları ayrı bir yerde toplama yaklaşımıdır.

Bir bankacılık uygulaması düşünelim. Para transferi yapılırken log atmak isteriz. Aynı işlemde audit kaydı tutmak isteriz. Belki yetki kontrolü yapmak isteriz. Belki methodun ne kadar sürdüğünü ölçmek isteriz. Bu ihtiyaçlar sadece transfer metoduna özel değildir; hesap açma, müşteri güncelleme, işlem geçmişi görüntüleme gibi birçok yerde tekrar eder.

Eğer bu ortak işleri her methodun içine tek tek yazarsak business kodun amacı bulanıklaşır. transfer() metodu sadece para transferi yapıyor gibi görünmez; log, audit, güvenlik, performans ölçümü, hata formatlama gibi yan işler de aynı methodun içine doluşur. AOP burada devreye girer ve şunu söyler: “Bu ortak davranışı ayrı bir yerde tanımlayalım, hangi methodlarda çalışacağını da kural olarak belirtelim.”

3.2 Aspect, Advice, Pointcut ve Join Point kavramları

AOP öğrenirken en çok kafa karıştıran şey kavramların isimleri olabilir. Aslında hepsi aynı cümleyi farklı parçalara böler: “Şu methodlar çalışırken, şu ortak davranışı çalıştır.”

@Aspect
@Component
public class AuditAspect {

    @Around("@annotation(auditable)") // Pointcut: @Auditable olan methodlar
    public Object audit(ProceedingJoinPoint joinPoint,
                        Auditable auditable) throws Throwable {
        // Advice: methodun etrafında çalışacak davranış
        long start = System.currentTimeMillis();

        try {
            Object result = joinPoint.proceed(); // Join point: gerçek method çalışır
            long duration = System.currentTimeMillis() - start;
            // Audit log burada oluşturulur
            return result;
        } catch (Throwable ex) {
            // Hata audit'i burada oluşturulur
            throw ex;
        }
    }
}

3.3 Spring AOP proxy mantığı

Spring AOP’yi anlamanın en kritik noktası şudur: Spring çoğu durumda gerçek bean’i doğrudan çağırmaz; onun önüne bir proxy koyar.

Proxy’yi bir kapı görevlisi gibi düşünebiliriz. Dışarıdan gelen çağrı önce proxy’ye gelir. Proxy “bu method için aspect çalışmalı mı?” diye bakar. Evetse önce advice’ı çalıştırır, sonra gerçek bean’e geçer. İş bitince dönüşte de tekrar araya girebilir.

Bu mekanizma sayesinde AccountOperationService içinde audit kodu yazmadan, o method çağrıldığında audit log oluşturabiliriz. Business kod sade kalır; audit davranışı merkezi bir aspect içinde yönetilir.

JDK Dynamic Proxy vs CGLIB

Spring AOP proxy üretirken genellikle iki yol kullanır. Eğer bean bir interface üzerinden proxylenecekse JDK Dynamic Proxy kullanılabilir. Interface yoksa veya class tabanlı proxy gerekiyorsa CGLIB devreye girer. Eğitim sırasında bu ayrımı ezberletmekten çok şunu oturtacağız: hangi yöntem kullanılırsa kullanılsın, çağrının proxy üzerinden geçmesi gerekir.

3.4 Advice türleri: @Before, @After, @Around

Advice, aspect’in method çağrısı sırasında ne yapacağını belirler. Her advice tipi farklı bir zamanlama için uygundur. Eğitimde özellikle @Around üzerinde duracağız, çünkü hem methoddan önce hem sonra çalışabilir, süre ölçebilir, hata yakalayabilir ve sonucu kontrol edebilir.

@Around("@annotation(auditable)")
public Object measureAndAudit(ProceedingJoinPoint joinPoint) throws Throwable {
    long start = System.currentTimeMillis();
    try {
        Object result = joinPoint.proceed();
        long duration = System.currentTimeMillis() - start;
        log.info("operation succeeded method={} duration={}ms",
                joinPoint.getSignature().getName(), duration);
        return result;
    } catch (Throwable ex) {
        log.warn("operation failed method={} error={}",
                joinPoint.getSignature().getName(), ex.getMessage());
        throw ex;
    }
}

3.5 @Transactional aslında AOP ile neden ilişkilidir?

@Transactional çoğu geliştirici için sadece annotation gibi görünür; ama arkasında proxy üzerinden çalışan bir davranış vardır.

Bir service methoduna @Transactional koyduğumuzda Spring o method çağrısını yakalayabilir. Methoda girmeden önce transaction başlatır, method başarılı biterse commit eder, exception fırlarsa rollback kararı verir. Bu davranışın business methodun içine yazılmaması büyük avantajdır.

Buradaki kritik nokta yine proxy’dir. Transaction davranışı methodun içine compile-time’da yapıştırılmaz. Runtime’da Spring proxy çağrıyı yakalar ve transaction yönetimini methodun etrafına sarar. Bu yüzden @Transactional çalışmadığında ilk kontrol edilecek konulardan biri method çağrısının proxy üzerinden geçip geçmediğidir.

3.6 Self-invocation problemi

Self-invocation, AOP’nin en önemli senior tuzaklarından biridir: aynı class içinden yapılan method çağrısı çoğu durumda proxy’ye uğramaz.

Diyelim ki TransferService içinde public bir method başka bir @Transactional methodu aynı class içinden çağırıyor. Kod okunurken “annotation var, transaction çalışır” diye düşünebiliriz. Ama çağrı this.innerMethod() gibi aynı obje üzerinde yapılıyorsa Spring proxy araya giremez. Çünkü dışarıdan proxy’ye gelen bir çağrı yoktur; obje kendi iç methodunu doğrudan çağırmıştır.

@Service
public class TransferService {

    public void transfer() {
        validate();
        saveAuditInNewTransaction(); // aynı class içinden çağrı
    }

    @Transactional
    public void saveAuditInNewTransaction() {
        // Transaction beklenir ama çağrı proxy'den geçmezse çalışmayabilir.
    }
}

@Service
@RequiredArgsConstructor
public class TransferService {
    private final AuditService auditService;

    public void transfer() {
        validate();
        auditService.saveAudit(); // başka bean üzerinden proxy'ye gider
    }
}

@Service
public class AuditService {
    @Transactional
    public void saveAudit() {
        // Transaction proxy üzerinden uygulanır.
    }
}