I’ve been thinking a lot lately about how we build systems that not only perform well but also maintain a clear history of every change. That’s what led me to explore Event Sourcing and CQRS - patterns that fundamentally change how we think about data and state in our applications.

Have you ever wondered what it would be like to have a complete audit trail of every action in your system? Event Sourcing makes this possible by storing all state changes as a sequence of immutable events. When combined with CQRS, which separates read and write operations, we get a powerful architecture that scales beautifully.

Let me show you how I implemented this using Spring Boot and Axon Framework. The first step is setting up our commands - these represent the intention to change something in our system.

public class CreateAccountCommand {
    @TargetAggregateIdentifier
    private final String accountId;
    private final String accountHolderName;
    private final BigDecimal initialBalance;
    
    // Constructor and getters
}

Notice how each command targets a specific aggregate? This is crucial for maintaining consistency boundaries. But what happens after a command is processed? That’s where events come in.

Events represent what actually occurred in the system. They’re immutable and contain all the information about the state change.

public class AccountCreatedEvent {
    private final String accountId;
    private final String accountHolderName;
    private final BigDecimal initialBalance;
    private final Instant timestamp;
    
    // Constructor and getters
}

Now, here’s where things get interesting. How do we ensure our aggregates handle these commands properly while maintaining their internal state? Let’s look at an account aggregate implementation.

@Aggregate
public class AccountAggregate {
    @AggregateIdentifier
    private String accountId;
    private BigDecimal balance;
    private String accountHolder;

    @CommandHandler
    public AccountAggregate(CreateAccountCommand command) {
        apply(new AccountCreatedEvent(
            command.getAccountId(),
            command.getAccountHolderName(),
            command.getInitialBalance()
        ));
    }

    @EventSourcingHandler
    public void on(AccountCreatedEvent event) {
        this.accountId = event.getAccountId();
        this.balance = event.getInitialBalance();
        this.accountHolder = event.getAccountHolderName();
    }
}

The beauty of this approach is that we can reconstruct the current state by replaying all events. But what about reading data? That’s where our read model comes in.

I set up MongoDB projections to handle the query side separately:

@Component
public class AccountProjection {
    
    private final MongoTemplate mongoTemplate;

    @EventHandler
    public void on(AccountCreatedEvent event) {
        AccountView account = new AccountView(
            event.getAccountId(),
            event.getAccountHolderName(),
            event.getInitialBalance()
        );
        mongoTemplate.save(account);
    }
}

This separation allows our read and write models to scale independently. The write side focuses on consistency while the read side optimizes for query performance.

Configuration is straightforward with Axon:

@Configuration
public class AxonConfig {
    
    @Bean
    public EventStore eventStore(MongoTemplate mongoTemplate) {
        return MongoEventStore.builder()
                .mongoTemplate(mongoTemplate)
                .build();
    }
}

What I love about this architecture is how it handles complex business processes. When a debit command comes in, the aggregate can validate business rules before emitting an event.

@CommandHandler
public void handle(DebitAccountCommand command) {
    if (balance.compareTo(command.getAmount()) < 0) {
        throw new InsufficientBalanceException();
    }
    apply(new AccountDebitedEvent(
        accountId,
        command.getAmount(),
        balance.subtract(command.getAmount()),
        command.getTransactionId()
    ));
}

The event sourcing part ensures we never lose this business logic - it’s captured forever in the event stream.

Testing becomes more straightforward too. We can verify that given certain events, our aggregate behaves as expected:

@Test
void testAccountCreation() {
    fixture.givenNoPriorActivity()
           .when(new CreateAccountCommand("acc1", "John Doe", new BigDecimal("1000")))
           .expectSuccessfulHandlerExecution();
}

What surprised me most was how this approach changes how we think about data. Instead of focusing on current state, we focus on the journey - the complete history of changes that led to the current state.

This architecture isn’t just about technical benefits though. It enables business stakeholders to understand exactly what happened and when, which is invaluable for compliance and debugging.

The combination of Spring Boot’s simplicity with Axon’s powerful abstractions makes this approach accessible without sacrificing power. MongoDB’s flexible document model works perfectly for storing both events and read projections.

I’d love to hear your thoughts on this approach. Have you implemented Event Sourcing in your projects? What challenges did you face? Share your experiences in the comments below and don’t forget to like and share this article if you found it helpful!