Hexalith.EventStore.SignalR 3.15.1

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

👁 GitHub stars
👁 NuGet
👁 Build
👁 Docs

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 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 .

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 .

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:

Getting Started

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

Concepts

• — system topology and design decisions
• — when Hexalith is (and isn't) the right fit
• — safely evolving event schemas over time

Guides

• — migrating between versions
• — honest answers about DAPR dependency, risks, and operational costs
• — Docker Compose, Kubernetes, Azure Container Apps
• — DAPR component configs, backend swap, secret management

Reference

• — command submission, status, replay, and preflight validation
• — query execution, ETag caching, projection notifications, and SignalR
• — package roles, dependencies, and installation guidance
• — auto-generated public type documentation

Community

• — planned features and project direction
• — curated ecosystem resources
• GitHub Discussions — questions, ideas, and community support
• Issue Tracker — bug reports and feature requests

Contributing

Contributions are welcome! Please read the and before submitting a pull request.

License

This project is licensed under the .

See the for release history and notable changes.