Sourcerer

I created Sourcerer as a lightweight event-sourcing framework for Rust.

The idea came from working with event-driven and domain-driven systems where the modelling approach is powerful, but the infrastructure can quickly become heavy. Event sourcing is conceptually elegant: instead of storing only the latest state of a system, you store the sequence of domain events that led to that state. That gives you history, auditability, replayability, and a much clearer link between business behaviour and code.

In practice, though, many event-sourcing frameworks either become too opinionated or try to own too much of the application. I wanted something smaller and more Rust-native: a framework that helped with the write side of a typical Command Query Responsibility Segregation architecture without forcing decisions about HTTP frameworks, projection systems, databases, or deployment models.

Sourcerer focuses on the core building blocks: aggregates, event stores, snapshots, optimistic locking, and event schema evolution. It provides storage abstractions with multiple back ends, including in-memory storage for tests, embedded sled storage, and Postgres support via sqlx. It also includes derive macros to remove some of the repetitive boilerplate around event metadata, versions, and sources.

The goal was not to hide event sourcing behind magic. The goal was to make the important parts explicit while smoothing over the parts that are repetitive, error-prone, or easy to get subtly wrong. Rust is a good fit for that kind of architecture: strong types, explicit error handling, and careful ownership make it natural to model domain events and aggregate behaviour precisely.

Sourcerer is still a small project, but it captures a lot of how I like to build software: start from the domain model, keep infrastructure pluggable, make state changes auditable, and use Rust’s type system to make the architecture harder to misuse.