I’ve been thinking about modern system architectures a lot lately, especially after working on an order management system where tracking every change became critical. What if you could reconstruct any past state of your application just by replaying events? That’s exactly what Event Sourcing enables, and today I’ll show you how to implement it using Spring Boot and Axon Framework.

When building transactional systems, traditional approaches store only the current state. But what happens when you need to know why something changed or how it looked yesterday? Event Sourcing solves this by persisting every state change as immutable events. We’ll create an order management system where every action becomes a permanent record.

Let’s start with dependencies. Here’s what your Maven file needs:

<dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
    </dependency>
    <dependency>
        <groupId>org.axonframework</groupId>
        <artifactId>axon-spring-boot-starter</artifactId>
        <version>4.9.0</version>
    </dependency>
    <dependency>
        <groupId>com.eventstore</groupId>
        <artifactId>db-client-java</artifactId>
        <version>23.10.0</version>
    </dependency>
</dependencies>

Commands initiate actions in our system. Notice how they target specific aggregates:

public class CreateOrderCommand {
    @TargetAggregateIdentifier
    private final String orderId;
    private final String customerId;
    // Constructor and getters
}

public class ShipOrderCommand {
    @TargetAggregateIdentifier
    private final String orderId;
    private final String trackingNumber;
    // Constructor and getters
}

But how do these commands translate into state changes? Events capture the facts:

public class OrderCreatedEvent {
    private final String orderId;
    private final Instant createdAt;
    // Constructor and getters
}

public class OrderShippedEvent {
    private final String orderId;
    private final String trackingNumber;
    // Constructor and getters
}

The OrderAggregate processes commands and produces events. Here’s the core structure:

@Aggregate
public class OrderAggregate {
    @AggregateIdentifier
    private String orderId;
    private OrderStatus status;

    @CommandHandler
    public OrderAggregate(CreateOrderCommand command) {
        apply(new OrderCreatedEvent(command.getOrderId()));
    }

    @EventSourcingHandler
    public void on(OrderCreatedEvent event) {
        this.orderId = event.getOrderId();
        this.status = OrderStatus.CREATED;
    }

    @CommandHandler
    public void handle(ShipOrderCommand command) {
        if (status != OrderStatus.CONFIRMED) {
            throw new IllegalStateException("Order must be confirmed first");
        }
        apply(new OrderShippedEvent(command.getOrderId(), command.getTrackingNumber()));
    }
}

Notice how commands are handled and events are applied. The @EventSourcingHandler rebuilds state. What happens if we need to handle complex workflows across aggregates? That’s where sagas shine:

@Saga
public class OrderFulfillmentSaga {
    @StartSaga
    @SagaEventHandler(associationProperty = "orderId")
    public void handle(OrderCreatedEvent event) {
        // Initiate payment process
    }

    @SagaEventHandler(associationProperty = "orderId")
    public void handle(PaymentReceivedEvent event) {
        // Trigger shipping process
    }
}

For read models, we project events to specialized views:

@EventHandler
public void on(OrderCreatedEvent event, @Timestamp Instant timestamp) {
    orderViewRepository.save(new OrderView(
        event.getOrderId(), 
        "NEW",
        timestamp
    ));
}

Testing is crucial. Axon’s test fixtures help:

@Test
void testOrderCreation() {
    fixture.givenNoPriorActivity()
           .when(new CreateOrderCommand("order1", "cust123"))
           .expectEvents(new OrderCreatedEvent("order1", "cust123"));
}

Performance tip: Use snapshotting for aggregates with many events:

@Bean
public SnapshotTriggerDefinition snapshotTrigger(Configuration config) {
    return new EventCountSnapshotTriggerDefinition(config.snapshotter(), 50);
}

Have you considered how event versioning affects schema evolution? Always design events with forward compatibility using optional fields and avoid breaking changes. For event storage, we use EventStoreDB configured in Axon:

axon:
  eventhandling:
    processor:
      default:
        mode: tracking
  eventsourcing:
    eventstore:
      event-store: eventStoreDB

What makes this architecture so powerful? Complete audit trails, temporal queries, and resilience. Replaying events recovers state after failures. But remember: Event Sourcing adds complexity, so evaluate if your domain justifies it.

I’d love to hear about your experiences with event-driven architectures! If you found this useful, please share it with others facing similar challenges. What techniques have worked in your projects? Let me know in the comments below.