I’ve been thinking a lot about how we build systems that truly remember their history. Traditional approaches often lose valuable context about why things happened, leaving us with just the current state. This limitation became particularly clear when I worked on complex business domains where understanding the sequence of decisions mattered just as much as the final outcome.

Event sourcing offers a different approach. Instead of storing only the current state, we capture every change as an immutable event. This creates a complete history of what happened, not just what currently exists. Have you ever wondered what your system was thinking three days ago at 2:47 PM? With event sourcing, you can know exactly.

Let me show you how to implement this using Spring Boot and Axon Framework. First, we’ll set up our project with the necessary dependencies. The Maven configuration includes Spring Boot starters, Axon Framework components, and Event Store database client.

<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.1</version>
    </dependency>
</dependencies>

The application configuration connects our components. We set up Axon to use event sourcing and configure the Event Store connection. Why do you think we separate event serialization from message serialization? It allows us to optimize how we store historical data versus how we communicate between services.

Now let’s create our domain model. Imagine we’re building an order management system. The Order aggregate becomes the centerpiece of our implementation:

@Aggregate
public class OrderAggregate {
    @AggregateIdentifier
    private String orderId;
    private OrderStatus status;
    
    @CommandHandler
    public OrderAggregate(CreateOrderCommand command) {
        apply(new OrderCreatedEvent(command.getOrderId(), 
                                   command.getCustomerId()));
    }
    
    @EventSourcingHandler
    public void on(OrderCreatedEvent event) {
        this.orderId = event.getOrderId();
        this.status = OrderStatus.CREATED;
    }
}

Commands represent intentions to change state, while events represent facts that have already occurred. This separation is crucial. What happens if we need to change how we interpret past events? The beauty of event sourcing is that we can rebuild our state differently without losing historical accuracy.

Here’s how we handle commands and generate events:

@CommandHandler
public void handle(ConfirmOrderCommand command) {
    if (this.status.canBeConfirmed()) {
        apply(new OrderConfirmedEvent(orderId, 
                                    LocalDateTime.now()));
    } else {
        throw new IllegalStateException("Order cannot be confirmed");
    }
}

Event handlers process these events to update projections. These projections serve as our query model, optimized for reading:

@EventHandler
public void on(OrderConfirmedEvent event, 
              @Timestamp Instant timestamp) {
    OrderView order = repository.findById(event.getOrderId());
    order.setStatus(OrderStatus.CONFIRMED);
    order.setConfirmedAt(timestamp);
    repository.save(order);
}

Testing event-sourced systems requires a different approach. We need to verify that commands produce the correct events and that events properly modify state:

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

Performance considerations become important as our event stream grows. Snapshotting helps optimize aggregate reconstruction:

@Bean
public SnapshotTriggerDefinition snapshotTriggerDefinition() {
    return new EventCountSnapshotTriggerDefinition(
        snapshotter, 50);
}

When implementing event sourcing, remember that it’s not just about technical implementation. It’s about changing how we think about state and time in our applications. The ability to replay history, build new projections from old events, and understand the complete story of our data transforms how we solve business problems.

What questions do you have about implementing this in your own projects? I’d love to hear about your experiences and challenges. If you found this useful, please share it with others who might benefit from this approach. Your comments and feedback help me create better content for our community.