Event Sourcing stores what happened, not just the latest state that resulted from it.

Event Sourcing replaces current-state storage as the primary source of truth with an append-only stream of domain events. That can be powerful when business history matters deeply, when reconstruction is valuable, or when projections must be rebuilt in different forms. It is also one of the most over-applied distributed patterns, so judgment matters.

OOAD landing page Learning roadmap Previous: CQRS Pattern Next: Saga Pattern

Why This Topic Matters

Why it matters in real Java systems

In ordering, knowing that an order was placed, payment authorized, stock reserved, shipment created, and refund issued is often more valuable than just seeing the latest status. Event Sourcing keeps that history explicit and reconstructable, which can be useful for audits, debugging, and multiple read models.

Core Explanation

The main design idea

With Event Sourcing, the system appends events such as OrderPlaced, PaymentAuthorized, and ShipmentCreated. Current state is rebuilt by replaying those events into an aggregate or projection. This can improve auditability and temporal reasoning, but it also introduces versioning, replay, and event evolution challenges.

Use Event Sourcing when the business meaning of historical change is central, not because events seem architecturally elegant. Many systems benefit more from ordinary persistence plus domain events than from full event sourcing.

Concept Breakdown

Key ideas to keep in mind

Concept

History is first-class

Past business actions remain explicit instead of being flattened into a single latest row.

Concept

State is derived

Current state comes from replaying events or maintaining projections.

Concept

Versioning matters

Events live long, so schema evolution and compatibility become major concerns.

Best-fit scenarios

Strong fit

Audit-heavy domains

Payments, compliance-sensitive workflows, and business timelines often benefit from a durable event history.

Strong fit

Temporal reasoning

When teams need to answer how and why the state changed over time, event streams are more honest than overwritten rows.

Weak fit

Simple CRUD systems

If the history is rarely useful and replay cost adds confusion, current-state persistence is usually better.

Weak fit

Teams without event discipline

Event sourcing magnifies naming, versioning, and compatibility mistakes.

Java Example

Java example in the Order Management domain

Java example: aggregate rebuilt from domain events

package org.javaomnibus.orders.eventsourcing;

public final class OrderAggregate {
    private OrderStatus status;

    public void apply(OrderPlaced event) {
        this.status = OrderStatus.PENDING_PAYMENT;
    }

    public void apply(PaymentAuthorized event) {
        this.status = OrderStatus.PAID;
    }

    public void apply(ShipmentCreated event) {
        this.status = OrderStatus.FULFILLING;
    }
}

Code Walkthrough

Step by step

The aggregate does not read one mutable row; it derives state from event application.
That makes the sequence of business changes visible and replayable.
In a real system, event versioning, snapshots, and projection rebuilding would also matter.
This power is real, but it is expensive enough that the use case should be compelling.

Real-World Usage

Where this helps in practice

Audit-heavy workflows
Temporal business analysis and state reconstruction
Event-driven systems where projections need to be rebuilt independently

Trade-Offs

Trade-offs and when to be careful

Event Sourcing offers rich history and flexible projections, but it adds schema evolution, replay, and debugging complexity.
Most teams should use it selectively for the few parts of the domain where history truly matters.

Common Mistakes

Frequent mistakes to watch for

Using Event Sourcing because 'microservices should use events'
Publishing technical events instead of stable domain events
Ignoring event versioning and migration plans
Assuming event logs remove the need for careful invariants

Related concepts

CQRS pattern Domain Events Outbox pattern