Hexalith.EventStore.Contracts 3.15.1

Hexalith.EventStore — DAPR-native event sourcing server for .NET

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.

The Programming Model

Your domain logic lives in an aggregate class with typed Handle methods — conceptually a pure function: $(Command, CurrentState?) \rightarrow List<DomainEvent>$. Each 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> implements IDomainProcessor — you can still use that interface directly for advanced scenarios (see the legacy CounterProcessor example).

Why Hexalith?

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.

Get Started

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 names

Beyond 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

Architecture

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

<details> <summary>Architecture diagram text description</summary>

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.

</details>

Documentation

Full documentation index: Documentation

Getting Started

• Quickstart Guide — up and running in under 10 minutes
• Prerequisites — required tools and environment setup

Concepts

• 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

Guides

• 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

Reference

• 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

Community

• 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

Contributing

Contributions are welcome! Please read the Contributing Guide and Code of Conduct before submitting a pull request.

License

This project is licensed under the MIT License.

See the Changelog for release history and notable changes.