My focus recently turned to an architectural pattern that changes how we think about state in our systems. Instead of just storing the current state of an object, like a bank balance, what if we stored every single change that ever happened to it? This idea, Event Sourcing, builds state from an immutable log of events. It’s a powerful shift in perspective that I wanted to explore practically, so I decided to implement it using the Axon Framework with Spring Boot.

Think about a bank account. In a traditional system, you have a table with an account ID and a current balance. When money moves, you update that number. With Event Sourcing, you don’t store the “current balance” directly. Instead, you store a sequence: “Account Opened with $100”, “$50 Deposited”, “$20 Withdrawn”. The current state is simply the sum of all those events. Why would you do this? It gives you a complete, trustworthy history by default. You can see exactly how the system arrived at any point, which is invaluable for debugging, compliance, and analytics.

I started by setting up a new Spring Boot project. The dependencies are straightforward but important. You need the Axon Spring Boot starter to bring in the framework and, for simplicity, I used an H2 in-memory database.

<dependency>
    <groupId>org.axonframework</groupId>
    <artifactId>axon-spring-boot-starter</artifactId>
    <version>4.8.0</version>
</dependency>
<dependency>
    <groupId>com.h2database</groupId>
    <artifactId>h2</artifactId>
    <scope>runtime</scope>
</dependency>

Axon needs to know how to store events and manage processing tokens. A basic configuration in application.yml and a couple of beans in the main class get everything wired up.

@Bean
public EventStorageEngine eventStorageEngine() {
    return JpaEventStorageEngine.builder()
            .entityManagerProvider(new SimpleEntityManagerProvider())
            .build();
}

The core of an Axon application is the Aggregate. This is the object that holds the business logic and state for write operations. For our bank account, the BankAccount aggregate listens for commands and produces events.

How does the aggregate know what its current balance is? It replays all the events for its ID. When it receives a DepositMoneyCommand, it validates the command and, if valid, applies a MoneyDepositedEvent. Applying the event means two things: the event is saved to the log, and the aggregate updates its own internal state by handling that same event. This ensures state changes only happen through events.

@Aggregate
public class BankAccount {
    @AggregateIdentifier
    private String accountId;
    private BigDecimal balance;
    private String owner;

    @CommandHandler
    public void handle(DepositMoneyCommand cmd) {
        if (cmd.getAmount().compareTo(BigDecimal.ZERO) <= 0) {
            throw new IllegalArgumentException("Deposit must be positive");
        }
        apply(new MoneyDepositedEvent(accountId, cmd.getAmount()));
    }

    @EventSourcingHandler
    public void on(MoneyDepositedEvent evt) {
        this.balance = this.balance.add(evt.getAmount());
    }
    // ... other command and event handlers
}

Commands are sent via a CommandGateway. But what happens to the events once they are stored? This is where Projections come in. While the aggregate is the “write model,” projections build specialized “read models” optimized for queries. A projection listens for events and updates a separate, query-friendly database table.

If you need to show a list of accounts on a dashboard, you wouldn’t replay events for each one. You’d query a projection table that was built up as those events occurred.

@Component
public class AccountProjection {
    @EventHandler
    public void on(AccountCreatedEvent evt, @Timestamp Instant timestamp) {
        // Insert a new record into a 'account_view' table
        // with fields like accountId, owner, balance, created_at
    }
}

This separation of writes and reads is CQRS (Command Query Responsibility Segregation). It allows you to scale and optimize each side independently. But what about business processes that span multiple aggregates? For instance, transferring money from Account A to Account B. You can’t have one aggregate directly modify another. This is a job for a Saga (or Process Manager). A Saga is a stateful component that listens for events and issues new commands to coordinate the process.

You start a MoneyTransferSaga when a TransferInitiatedEvent occurs. The saga then sends a WithdrawMoneyCommand to the source account. Upon seeing the MoneyWithdrawnEvent, it sends a DepositMoneyCommand to the target account. It manages the workflow, ensuring both sides complete or compensating if something fails. Can you see how this creates a system based on reacting to facts?

Testing becomes a different, often clearer, experience. With Axon’s test fixtures, you can set up a scenario by giving a list of past events, then send a command, and finally assert on the resulting events and aggregate state. You’re testing the business rules directly.

@Test
void testOverdraftPrevention() {
    fixture.given(new AccountCreatedEvent("acc1", "John", new BigDecimal("50")))
           .when(new WithdrawMoneyCommand("acc1", new BigDecimal("60"), "Rent"))
           .expectException(IllegalStateException.class);
}

This approach isn’t a silver bullet. It adds complexity. The event log can grow very large, requiring snapshotting strategies where you periodically save the full aggregate state to speed up replays. Designing your events carefully is critical; they are part of your public contract and should be rich in meaning. Querying for “current state” requires the projection, which introduces eventual consistency between your write and read models.

However, for systems where auditability, temporal querying, and modeling complex business processes are paramount, the benefits are substantial. You build a system that records not just what is, but how it came to be. It forces a discipline of modeling state changes explicitly.

I find this way of building systems to be both challenging and rewarding. It encourages you to think deeply about the core actions in your domain. What are the true, recordable facts? If you had to replay every user action to rebuild your application’s state, would your logic hold up?

Getting your hands dirty with Axon and Spring Boot is the best way to understand these concepts. Start with a simple domain, like our bank account, and gradually introduce projections and sagas. The mental model shift is significant, but the clarity it can bring to complex business logic is often worth the effort.

I hope this walkthrough gives you a solid starting point. If you’ve built systems with Event Sourcing or have questions about these patterns, I’d love to hear your thoughts. Please share your experiences in the comments below, and if you found this guide helpful, consider sharing it with others who might be on a similar architectural journey.