Have you ever wondered how systems manage complex state changes while maintaining a complete audit trail? That question led me to explore event sourcing after struggling with traditional CRUD approaches in my e-commerce projects. Today, I’ll share a practical implementation using Spring Boot, Axon Framework, and PostgreSQL that transformed how I handle business workflows.

Event sourcing fundamentally changes how we think about application state. Instead of storing current data, we capture every state change as immutable events. When combined with CQRS, this pattern separates write operations (commands) from read operations (queries), giving us flexibility and scalability. Axon Framework provides the scaffolding for this architecture, while PostgreSQL offers robust storage. Let’s build an order management system together.

First, we set up our environment. Here’s the Maven configuration I use:

<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>org.postgresql</groupId>
    <artifactId>postgresql</artifactId>
  </dependency>
</dependencies>

Our domain model starts with commands - intentions to change state. Notice how each command targets a specific aggregate:

public record CreateOrderCommand(
  @TargetAggregateIdentifier String orderId,
  String customerId,
  List<OrderItem> items
) {}

public record ShipOrderCommand(
  @TargetAggregateIdentifier String orderId,
  String trackingNumber
) {}

Events become our source of truth. They represent facts that occurred in our system:

public record OrderCreatedEvent(
  String orderId,
  String customerId,
  Instant timestamp
) {}

public record OrderShippedEvent(
  String orderId,
  String trackingNumber,
  Instant timestamp
) {}

The OrderAggregate processes commands and produces events. How do we ensure state consistency? Through event sourcing handlers:

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

  @CommandHandler
  public OrderAggregate(CreateOrderCommand command) {
    apply(new OrderCreatedEvent(
      command.orderId(),
      command.customerId(),
      Instant.now()
    ));
  }

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

For PostgreSQL configuration, we handle both event storage and read models:

axon:
  eventhandling:
    processors:
      order-projection:
        mode: tracking
        source: eventBus

spring:
  datasource:
    url: jdbc:postgresql://localhost/event_store
    username: postgres

Projections transform events into queryable views. This separation allows read optimizations:

@ProcessingGroup("order-projection")
public class OrderProjection {
  @EventHandler
  public void addOrder(OrderCreatedEvent event, 
                       @Timestamp Instant timestamp) {
    // Insert into read-optimized PostgreSQL table
  }
}

When business processes span multiple aggregates, sagas coordinate the workflow:

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

Testing event-sourced systems requires a different approach. Axon’s test fixtures verify command-event interactions:

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

Performance considerations? Event replay allows rebuilding state from scratch, while snapshotting optimizes load times. PostgreSQL’s JSONB support efficiently stores event payloads. Remember to index aggregate identifiers for fast lookups.

What challenges might you face with schema changes? I handle event versioning through upcasters that transform legacy events:

public class OrderEventUpcaster extends SingleEventUpcaster {
  @Override
  public Object doUpcast(SerializedObject<?> input) {
    // Transform old event format to new
  }
}

This approach has transformed how I build resilient systems. The complete audit trail helps with compliance, while CQRS enables scaling reads independently. Event sourcing does introduce complexity, but for mission-critical workflows, the benefits outweigh the costs.

If you found this walkthrough helpful, share it with your team or leave a comment about your event sourcing experiences. What problems could this solve in your current projects?