I’ve been thinking a lot about how we build systems that not only work well today but remain understandable and maintainable years from now. This led me to explore Event Sourcing, particularly with EventStore and NestJS, as a way to create applications that preserve their entire history while staying performant and scalable. Let me share what I’ve learned.

What if your application could remember every change ever made, not just its current state? Event Sourcing makes this possible by storing sequences of state-changing events rather than just the final result. This approach gives you a complete audit trail, enables time-travel debugging, and naturally supports event-driven architectures.

Getting started requires a solid foundation. Here’s how I set up a NestJS project with EventStore:

// eventstore.config.ts
import { EventStoreDBClient } from '@eventstore/db-client';

export const createEventStoreClient = () => {
  return EventStoreDBClient.connectionString(
    process.env.EVENTSTORE_CONNECTION_STRING || 
    'esdb://localhost:2113?tls=false'
  );
};

Have you considered how events become the source of truth in your system? Instead of updating records, we record what happened. This shift in perspective changes how we model our domain. Let me show you how I structure domain events:

// account.events.ts
export class AccountCreatedEvent {
  constructor(
    public readonly aggregateId: string,
    public readonly accountNumber: string,
    public readonly ownerId: string,
    public readonly initialBalance: number
  ) {}
}

export class MoneyDepositedEvent {
  constructor(
    public readonly aggregateId: string,
    public readonly amount: number,
    public readonly transactionId: string
  ) {}
}

The real power emerges when we build aggregates that reconstruct their state from events. Here’s how I implement an event-sourced aggregate:

// account.aggregate.ts
export class AccountAggregate extends BaseAggregateRoot {
  private balance: number = 0;
  private isActive: boolean = false;

  static create(accountId: string, ownerId: string): AccountAggregate {
    const account = new AccountAggregate(accountId);
    account.apply(new AccountCreatedEvent(accountId, ownerId));
    return account;
  }

  deposit(amount: number, transactionId: string): void {
    if (!this.isActive) throw new Error('Account not active');
    this.apply(new MoneyDepositedEvent(this.id, amount, transactionId));
  }

  private onAccountCreated(event: AccountCreatedEvent): void {
    this.balance = event.initialBalance;
    this.isActive = true;
  }

  private onMoneyDeposited(event: MoneyDepositedEvent): void {
    this.balance += event.amount;
  }
}

But how do we make this data useful for queries? That’s where CQRS and projections come in. I create separate read models optimized for specific queries:

// account-projection.ts
@EventHandler(AccountCreatedEvent)
export class AccountProjection {
  constructor(private readonly repository: Repository<AccountReadModel>) {}

  async handle(event: AccountCreatedEvent): Promise<void> {
    const account = new AccountReadModel();
    account.id = event.aggregateId;
    account.balance = event.initialBalance;
    account.ownerId = event.ownerId;
    await this.repository.save(account);
  }
}

Testing becomes more straightforward when you can replay events to recreate any state. I often write tests that verify specific event sequences produce expected outcomes:

// account.test.ts
it('should handle multiple deposits correctly', async () => {
  const account = AccountAggregate.create('acc-1', 'user-1');
  account.deposit(100, 'tx-1');
  account.deposit(200, 'tx-2');
  
  const events = account.getUncommittedEvents();
  expect(events).toHaveLength(3);
  expect(events[2].data.amount).toBe(200);
});

What challenges might you face when events need to change over time? Event versioning requires careful planning. I use upcasters to transform old event formats into new ones:

// event-upcaster.ts
export class AccountEventUpcaster {
  upcast(event: any): any {
    if (event.eventType === 'AccountCreated' && event.eventVersion === 1) {
      return {
        ...event,
        data: { ...event.data, currency: 'USD' },
        eventVersion: 2
      };
    }
    return event;
  }
}

The beauty of this approach lies in its simplicity and power. You’re building systems that naturally support features like audit logs, time travel, and complex business workflows. The initial investment in learning Event Sourcing pays dividends as your application grows in complexity.

I’d love to hear about your experiences with Event Sourcing or any questions you might have. If this approach resonates with you, please share it with others who might benefit from building more maintainable, scalable systems. What aspects of Event Sourcing are you most excited to try in your next project?