If you've spent weeks wiring up an event store, a message broker, multi-tenant isolation, and a read-model refresh story — only to realize you'll do it again for your next project — we built this for you. Hexalith.EventStore is a distributed, CQRS and DDD-ready event sourcing framework that handles command routing, event persistence, snapshots, query execution, and pub/sub delivery so you can focus on domain logic. Built on DAPR for infrastructure portability.
Your domain logic lives in an aggregate class with typed Handle methods — conceptually a pure function: Handle method receives a specific command and the current state, then returns a DomainResult carrying success events or rejections.
public sealed class CounterAggregate : EventStoreAggregate<CounterState>
{
public static DomainResult Handle(IncrementCounter command, CounterState? state)
=> DomainResult.Success(new IEventPayload[] { new CounterIncremented() });
public static DomainResult Handle(DecrementCounter command, CounterState? state)
{
if ((state?.Count ?? 0) == 0)
return DomainResult.Rejection(new IRejectionEvent[] { new CounterCannotGoNegative() });
return DomainResult.Success(new IEventPayload[] { new CounterDecremented() });
}
public static DomainResult Handle(ResetCounter command, CounterState? state)
{
if ((state?.Count ?? 0) == 0)
return DomainResult.NoOp();
return DomainResult.Success(new IEventPayload[] { new CounterReset() });
}
}
public sealed class CounterState
{
public int Count { get; private set; }
public void Apply(CounterIncremented e) => Count++;
public void Apply(CounterDecremented e) => Count--;
public void Apply(CounterReset e) => Count = 0;
}Under the hood,
EventStoreAggregate<TState>implementsIDomainProcessor— you can still use that interface directly for advanced scenarios (see the legacyCounterProcessorexample).
| Feature | Hexalith | Marten | EventStoreDB | Custom |
|---|---|---|---|---|
| Infrastructure portability | Any store/broker, zero-code swap | PostgreSQL only | Dedicated server | You build it |
| Multi-tenant isolation | Built-in: data, topics, access | Manual | Manual | You build it |
| CQRS/ES framework | Complete, infra-agnostic | Complete, PG-coupled | Storage only, BYO framework | You build it |
| Deployment | DAPR sidecar: Docker, K8s, ACA | App library | Server + clients | You build it |
| Database lock-in | None (Redis, PG, Cosmos, etc.) | PostgreSQL | EventStoreDB | Chosen DB |
Note: Hexalith is not the right tool for every scenario. If you need raw event stream performance or already run PostgreSQL everywhere, see the decision aid.
Register the event store in two lines — AddEventStore() scans your assembly for aggregate types, no manual registration needed:
builder.Services.AddEventStore(); // Auto-discovers CounterAggregate
// ...
app.UseEventStore(); // Activates domains with convention-derived namesBeyond commands, the platform includes a query pipeline with ETag-based cache validation, projection invalidation hooks, preflight authorization endpoints, and optional SignalR notifications for real-time read-model refresh.
Get started in under 10 minutes — follow the Quickstart Guide.
Prerequisites: .NET SDK, Docker Desktop, DAPR CLI
flowchart TB
Client([Client Application]) -->|REST commands + queries| CommandAPI[Command API Gateway]
Realtime[Realtime UI / Client] <-.->|SignalR change notifications| CommandAPI
CommandAPI -->|Route command| Actor[Aggregate Actor]
Actor -->|Invoke| Domain[Domain Service<br/>IDomainProcessor]
Domain -->|Return events| Actor
Actor -->|Persist| StateStore[(State Store<br/>Redis / PostgreSQL / Cosmos DB)]
Actor -->|Publish| PubSub{{Pub/Sub<br/>RabbitMQ / Kafka / Azure Service Bus}}
PubSub -->|Subscribe| Projections[Event Handlers / Projections]
Projections -->|Projection changed| CommandAPI
subgraph DAPR ["DAPR Sidecar (Infrastructure Abstraction)"]
StateStore
PubSub
end
Architecture diagram text description
The system follows a command-event architecture with a built-in read-model refresh path: client applications send commands and queries via REST to the Command API Gateway, which routes commands to Aggregate Actors and queries to projection handlers. Each actor invokes the domain service (your IDomainProcessor implementation) and persists resulting events to a state store. Events are published to a pub/sub system for downstream consumers, and projection changes can be surfaced back to clients through HTTP cache validators and optional SignalR notifications. DAPR provides the infrastructure abstraction layer, allowing you to swap state stores (Redis, PostgreSQL, Cosmos DB) and message brokers (RabbitMQ, Kafka, Azure Service Bus) without changing application code.
Full documentation index: Documentation
- Quickstart Guide — up and running in under 10 minutes
- Prerequisites — required tools and environment setup
- Architecture Overview — system topology and design decisions
- Choose the Right Tool — when Hexalith is (and isn't) the right fit
- Event Versioning & Schema Evolution — safely evolving event schemas over time
- Upgrade Path — migrating between versions
- DAPR FAQ Deep Dive — honest answers about DAPR dependency, risks, and operational costs
- Deployment Guides — Docker Compose, Kubernetes, Azure Container Apps
- Production Deployment Configuration — DAPR component configs, backend swap, secret management
- Command API Reference — command submission, status, replay, and preflight validation
- Query & Projection API Reference — query execution, ETag caching, projection notifications, and SignalR
- NuGet Packages Guide — package roles, dependencies, and installation guidance
- Generated API Reference — auto-generated public type documentation
- Product Roadmap — planned features and project direction
- Awesome Event Sourcing — curated ecosystem resources
- GitHub Discussions — questions, ideas, and community support
- Issue Tracker — bug reports and feature requests
Contributions are welcome! Please read the Contributing Guide and Code of Conduct before submitting a pull request.
This project is licensed under the MIT License.
See the Changelog for release history and notable changes.