I’ve been thinking a lot about how we build systems that not only handle current state but remember every change that led to it. Traditional approaches often leave us with just the present moment, losing the valuable story of how we got here. That’s why I want to share how we can implement event sourcing with Spring Boot, Axon Framework, and MongoDB.

What if your application could remember every single change that ever happened? This isn’t just theoretical—it’s practical and powerful.

Let me show you how to set this up. First, we need our dependencies. Here’s the Maven configuration:

<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.8.3</version>
    </dependency>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-data-mongodb</artifactId>
    </dependency>
</project>

Now, imagine we’re building an order system. We start by defining our events—these are the building blocks of our system’s memory:

public class OrderCreatedEvent {
    private String orderId;
    private String customerId;
    private BigDecimal totalAmount;
    
    // Constructors and getters
}

public class OrderConfirmedEvent {
    private String orderId;
    private Instant confirmedAt;
    
    // Constructors and getters
}

Have you considered how these events become the single source of truth for your application’s history?

The aggregate is where the magic happens. It processes commands and produces events:

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

Configuring MongoDB as our event store is straightforward:

@Configuration
public class AxonConfig {
    @Bean
    public EventStorageEngine storageEngine(MongoClient client) {
        return MongoEventStorageEngine.builder()
            .mongoTemplate(DefaultMongoTemplate.builder()
                .mongoDatabase(client)
                .build())
            .build();
    }
}

Now, what happens when we need to show data to users? That’s where projections come in:

@ProcessingGroup("orders")
public class OrderProjection {
    private final MongoTemplate mongoTemplate;
    
    @EventHandler
    public void on(OrderCreatedEvent event) {
        OrderView order = new OrderView(
            event.getOrderId(),
            event.getCustomerId(),
            event.getTotalAmount(),
            "CREATED"
        );
        mongoTemplate.save(order);
    }
}

Testing is crucial in event-sourced systems. Here’s how we verify our aggregate behavior:

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

As we build more complex processes, sagas help coordinate across multiple aggregates:

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

One challenge we often face is event versioning. How do we handle changes to our event structure over time? Axon provides tools for this, but careful design from the start is essential.

Performance considerations are important too. MongoDB’s indexing capabilities help us maintain fast read operations while handling high volumes of events.

I’ve found that starting with clear event definitions and maintaining consistency in how we handle state changes makes the entire system more maintainable. The audit trail and ability to reconstruct state at any point in time have proven invaluable in production systems.

What questions do you have about implementing this in your own projects? I’d love to hear about your experiences and challenges with event sourcing.

If you found this helpful, please share it with others who might benefit. Your comments and feedback help me create better content for everyone. Let me know what other topics you’d like me to cover!