Spring Boot 4 Complete Guide · Pelajaran

Peristiwa dan Pendengar Aplikasi Internal

Pisahkan modul menggunakan peristiwa domain yang diterbitkan dan dikonsumsi dalam konteks aplikasi.

Pelajaran 2 dari 413 langkah

Peristiwa dan Pendengar Aplikasi Internal adalah pelajaran Spring Boot 4 Complete Guide gratis di CoddyKit. Ini adalah pelajaran 2 dari 4. Kamu bisa membaca pelajaran lengkapnya di bawah secara gratis — lalu praktikkan langsung di browser dengan editor kode bawaan dan tutor AI 24/7. Ini adalah bagian dari jalur belajar Spring Boot 4 Complete Guide, dan progresmu tersinkronisasi di web dan aplikasi CoddyKit. Kursus Spring Boot 4 Complete Guide mencakup 4 pelajaran total.

Bagian dari pelajaran ini belum diterjemahkan dan ditampilkan dalam bahasa Inggris.

Why Decouple Modules with Events?

In a modular monolith, an Order module often needs to trigger work in other modules: send a confirmation email, update inventory, award loyalty points. The naive approach is to have OrderService call EmailService, InventoryService, and LoyaltyService directly.

This creates tight coupling — Order depends on every downstream module.
Adding a new reaction means editing OrderService again.
Modules can no longer evolve or be tested independently.

Spring's internal application events invert this: the Order module simply publishes a domain event, and interested modules listen for it. The publisher never knows who is listening.

The Domain Event Record

An internal event is just a plain object — in Spring Boot 4 (Java 21+) a record is the idiomatic choice. It should be immutable and carry only the data listeners need.

Name it in the past tense (OrderCompleted) — it describes something that already happened.
Keep it inside the owning module's package.
No Spring annotations are required on the event itself.

package com.shop.order;

import java.math.BigDecimal;
import java.util.UUID;

public record OrderCompleted(
        UUID orderId,
        String customerEmail,
        BigDecimal total) {
}

Publishing an Event

The owning module publishes the event through Spring's ApplicationEventPublisher. Inject it via the constructor and call publishEvent() after the business operation succeeds.

The publisher has no compile-time reference to any listener.
By default publishing is synchronous — listeners run on the same thread, inside the same transaction.

package com.shop.order;

import org.springframework.context.ApplicationEventPublisher;
import org.springframework.stereotype.Service;
import org.springframework.transaction.annotation.Transactional;

@Service
public class OrderService {

    private final ApplicationEventPublisher events;
    private final OrderRepository orders;

    public OrderService(ApplicationEventPublisher events, OrderRepository orders) {
        this.events = events;
        this.orders = orders;
    }

    @Transactional
    public void complete(Order order) {
        order.markCompleted();
        orders.save(order);
        events.publishEvent(
            new OrderCompleted(order.getId(), order.getCustomerEmail(), order.getTotal()));
    }
}

Listening with @EventListener

Any Spring bean in another module can react by annotating a method with @EventListener. The single method parameter declares the event type the listener cares about.

The method can have any name — Spring matches on the parameter type.
The listener lives in its own module (com.shop.notification) and never references the Order service.

package com.shop.notification;

import com.shop.order.OrderCompleted;
import org.springframework.context.event.EventListener;
import org.springframework.stereotype.Component;

@Component
public class OrderEmailListener {

    private final MailSender mail;

    public OrderEmailListener(MailSender mail) {
        this.mail = mail;
    }

    @EventListener
    void on(OrderCompleted event) {
        mail.send(event.customerEmail(),
                  "Your order " + event.orderId() + " is complete!");
    }
}

Synchronous by Default — and Its Risks

By default publishEvent() invokes every matching @EventListener synchronously, in order, on the calling thread. Because the listeners run inside the publisher's transaction:

A listener that throws will propagate the exception back to the publisher and roll back the whole transaction.
A slow listener (e.g. sending an email) blocks the business call until it finishes.

This is rarely what you want for side effects like email. The next scenes show how to fix both problems with transaction-bound and asynchronous listeners.

Reacting Only After Commit

You usually want side effects to fire only if the transaction actually commits — you should not send a "your order is complete" email if the order save later rolls back. Use @TransactionalEventListener, which by default binds to the AFTER_COMMIT phase.

The listener runs after the publisher's transaction commits successfully.
If the transaction rolls back, the listener is skipped.
You can choose other phases via phase = BEFORE_COMMIT, AFTER_ROLLBACK, or AFTER_COMPLETION.

package com.shop.notification;

import com.shop.order.OrderCompleted;
import org.springframework.stereotype.Component;
import org.springframework.transaction.event.TransactionPhase;
import org.springframework.transaction.event.TransactionalEventListener;

@Component
public class OrderEmailListener {

    private final MailSender mail;

    public OrderEmailListener(MailSender mail) {
        this.mail = mail;
    }

    @TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
    void on(OrderCompleted event) {
        mail.send(event.customerEmail(),
                  "Your order " + event.orderId() + " is complete!");
    }
}

Making Listeners Asynchronous

To stop a slow listener from blocking the caller, add @Async. The listener then runs on a separate thread from a task executor, so publishEvent() returns immediately.

Enable async support once with @EnableAsync on a configuration class.
Important: an @Async listener runs in its own thread with no transaction and no access to the publisher's context. Combine it with @TransactionalEventListener(AFTER_COMMIT) when you want "after commit, on a background thread."
Async listeners that throw are logged but do not affect the publisher — handle failures yourself.

package com.shop.notification;

import com.shop.order.OrderCompleted;
import org.springframework.scheduling.annotation.Async;
import org.springframework.stereotype.Component;
import org.springframework.transaction.event.TransactionalEventListener;

@Component
public class OrderEmailListener {

    private final MailSender mail;

    public OrderEmailListener(MailSender mail) {
        this.mail = mail;
    }

    @Async
    @TransactionalEventListener
    void on(OrderCompleted event) {
        mail.send(event.customerEmail(),
                  "Your order " + event.orderId() + " is complete!");
    }
}

Spring Modulith Event Externalization

Plain Spring events are in-memory only: if the application crashes between commit and the listener running, the event is lost. Spring Modulith adds durability with its Event Publication Registry.

Add the spring-modulith-events-jpa (or JDBC/MongoDB) starter.
Each @TransactionalEventListener invocation is recorded in an event_publication table within the same transaction.
Once the listener completes, its publication is marked as completed. Incomplete publications can be republished on restart, guaranteeing at-least-once delivery.

Configuring the Publication Registry

With the events starter on the classpath, Modulith auto-creates the registry schema and wires interception. A little YAML controls recovery behaviour.

republish-outstanding-events-on-restart resubmits any publications that never completed before the last shutdown.
Modulith also exposes the registry so you can monitor or manually resubmit stuck events.

spring:
  modulith:
    events:
      jdbc:
        schema-initialization:
          enabled: true
      republish-outstanding-events-on-restart: true
      completion-mode: delete

Filtering Events by Condition

Sometimes a listener should only react to some events of a type. The condition attribute takes a SpEL expression evaluated against the event; the listener runs only when it returns true.

Reference the event payload with #root.event or simply the property via # root.
This keeps filtering declarative instead of an if at the top of the method.

package com.shop.loyalty;

import com.shop.order.OrderCompleted;
import org.springframework.context.event.EventListener;
import org.springframework.stereotype.Component;

@Component
public class HighValueOrderListener {

    // Only fires for orders over 100
    @EventListener(condition = "#event.total().compareTo(new java.math.BigDecimal('100')) > 0")
    void onBigOrder(OrderCompleted event) {
        // award bonus loyalty points
    }
}

A Standalone Pub/Sub Mental Model

Strip away Spring and the pattern is just a registry of listeners keyed by event type. The snippet below is a plain Java program that mimics the synchronous publish/subscribe behaviour — useful to internalize what ApplicationEventPublisher does under the hood.

import java.util.*;
import java.util.function.Consumer;

public class MiniEventBus {
    private final Map<Class<?>, List<Consumer<Object>>> listeners = new HashMap<>();

    <T> void subscribe(Class<T> type, Consumer<T> listener) {
        listeners.computeIfAbsent(type, k -> new ArrayList<>())
                 .add(e -> listener.accept(type.cast(e)));
    }

    void publish(Object event) {
        listeners.getOrDefault(event.getClass(), List.of())
                 .forEach(l -> l.accept(event));
    }

    record OrderCompleted(String id, double total) {}

    public static void main(String[] args) {
        MiniEventBus bus = new MiniEventBus();
        bus.subscribe(OrderCompleted.class,
                e -> System.out.println("Email: order " + e.id() + " done"));
        bus.subscribe(OrderCompleted.class,
                e -> System.out.println("Loyalty: +" + (int) e.total() + " points"));
        bus.publish(new OrderCompleted("A-42", 150.0));
    }
}

Quick Check: Choosing the Right Listener

You publish an OrderCompleted event inside a @Transactional order-save method. The email listener must run only if the order is actually persisted, and it must not delay or break the order-save call. Which listener configuration is correct?

Jawab di pelajaran interaktif

Recap: Internal Events for Module Decoupling

You learned how to decouple modules with in-application domain events:

Model events as immutable past-tense records owned by the publishing module.
Publish via ApplicationEventPublisher.publishEvent() — the publisher never references listeners.
React with @EventListener (synchronous, in-transaction) or @TransactionalEventListener (runs in a chosen transaction phase, default AFTER_COMMIT).
Add @Async + @EnableAsync to run side effects off the caller's thread.
Filter declaratively with the condition SpEL attribute.
Use Spring Modulith's Event Publication Registry to persist publications and republish incomplete ones on restart for reliable, at-least-once delivery.

The result: modules that communicate through events stay independently testable, replaceable, and free of direct dependencies.

Gratis untuk memulai

Belajar Java dengan tutor AI — gratis

Tulis dan jalankan kode asli di browser kamu, dapatkan bantuan instan dari tutor AI 24/7, dan lanjutkan di mana kamu tinggalkan di web atau aplikasi.

Kursus: 21
Pelajaran: 84

Mulai belajar gratis Lihat kursus lengkapnya

Pertanyaan yang Sering Diajukan

Apakah pelajaran “Peristiwa dan Pendengar Aplikasi Internal” gratis?

Ya — teks lengkap “Peristiwa dan Pendengar Aplikasi Internal” gratis dibaca di sini di web. Untuk praktiknya secara interaktif (editor kode bawaan dan tutor AI 24/7) dan buka sisa kursus Spring Boot 4 Complete Guide, upgrade ke CoddyKit PRO. Kursus Spring Boot 4 Complete Guide mencakup 4 pelajaran total.

Apa yang akan aku pelajari di “Peristiwa dan Pendengar Aplikasi Internal”?

Pisahkan modul menggunakan peristiwa domain yang diterbitkan dan dikonsumsi dalam konteks aplikasi. Kamu berlatih Spring Boot 4 Complete Guide dengan kode praktik yang langsung kamu jalankan di browser, dan tutor AI 24/7 menjawab pertanyaanmu saat kamu mengerjakan pelajaran ini.

Apakah aku perlu pengalaman untuk memulai Spring Boot 4 Complete Guide?

Tidak diperlukan pengalaman sebelumnya. Spring Boot 4 Complete Guide di CoddyKit dirancang untuk pemula hingga pelajar tingkat lanjut, jadi kamu bisa memulai di sini atau dari awal dan belajar sesuai kecepatan kamu sendiri. Ini adalah pelajaran 2 dari 4.

Berapa lama pelajaran “Peristiwa dan Pendengar Aplikasi Internal” memakan waktu?

Sebagian besar pelajaran CoddyKit memakan waktu sekitar 5–10 menit. Setiap pelajaran ringkas dan interaktif, jadi kamu membuat kemajuan stabil dan melanjutkan dari tempat kamu tinggalkan di web dan aplikasi.

Bisakah aku menulis dan menjalankan kode dalam pelajaran Spring Boot 4 Complete Guide ini?

Ya. Setiap pelajaran Spring Boot 4 Complete Guide menyertakan editor kode bawaan, jadi kamu menulis dan menjalankan kode nyata langsung di browser dan mendapatkan umpan balik AI instan — tidak diperlukan penyiapan lokal.

Semua pelajaran dalam kursus ini

Modul Aplikasi dan Verifikasi Batas
Peristiwa dan Pendengar Aplikasi Internal
Penerbitan Peristiwa Transaksional dan Outbox
Pengujian Integrasi Modul dan Skenario

← Kembali ke Spring Boot 4 Complete Guide