Hexalith.EventStore.Testing.Integration 3.128.0

There is a newer version of this package available.
See the version list below for details.
dotnet add package Hexalith.EventStore.Testing.Integration --version 3.128.0
                    
NuGet\Install-Package Hexalith.EventStore.Testing.Integration -Version 3.128.0
                    
This command is intended to be used within the Package Manager Console in Visual Studio, as it uses the NuGet module's version of Install-Package.
<PackageReference Include="Hexalith.EventStore.Testing.Integration" Version="3.128.0" />
                    
For projects that support PackageReference, copy this XML node into the project file to reference the package.
<PackageVersion Include="Hexalith.EventStore.Testing.Integration" Version="3.128.0" />
                    
Directory.Packages.props
<PackageReference Include="Hexalith.EventStore.Testing.Integration" />
                    
Project file
For projects that support Central Package Management (CPM), copy this XML node into the solution Directory.Packages.props file to version the package.
paket add Hexalith.EventStore.Testing.Integration --version 3.128.0
                    
#r "nuget: Hexalith.EventStore.Testing.Integration, 3.128.0"
                    
#r directive can be used in F# Interactive and Polyglot Notebooks. Copy this into the interactive tool or source code of the script to reference the package.
#:package Hexalith.EventStore.Testing.Integration@3.128.0
                    
#:package directive can be used in C# file-based apps starting in .NET 10 preview 4. Copy this into a .cs file before any lines of code to reference the package.
#addin nuget:?package=Hexalith.EventStore.Testing.Integration&version=3.128.0
                    
Install as a Cake Addin
#tool nuget:?package=Hexalith.EventStore.Testing.Integration&version=3.128.0
                    
Install as a Cake Tool

Quickstart demo: Aspire dashboard showing services running, a command sent via Swagger UI, and the resulting event in the event stream

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

GitHub stars NuGet Build Docs License: MIT

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?

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.

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

Run and Debug in the Platform Workspace

EventStore runs and debugs as a module from the Hexalith.Platform workspace, where this repository is the references/Hexalith.EventStore submodule. From the Platform root, with the pinned module tool, Aspire CLI 13.6.1 exactly, Docker, and HEXALITH_DAPR_HOME pointing at an isolated Dapr home (CLI 1.18.0 at tools/dapr, runtime 1.18.2 in .dapr/bin):

dotnet tool restore
dotnet restore apphost.cs
dotnet tool run hexalith-module -- debug --manifest references/Hexalith.EventStore/module/hexalith.module-manifest.v2.json
dotnet tool run hexalith-module -- down --manifest references/Hexalith.EventStore/module/hexalith.module-manifest.v2.json

Initialize the Platform workspace's direct references/Hexalith.Builds, references/Hexalith.EventStore, references/Hexalith.Tenants and references/Hexalith.Memories checkouts without --recursive, with each HEAD matching its staged Platform gitlink. The tool reads all three declaration owners even for EventStore alone. dotnet restore apphost.cs installs the local Aspire orchestration and dashboard packages before the first run; tool restore alone does not. If NuGet uses a custom globalPackagesFolder, set NUGET_PACKAGES to that absolute folder for both restore and debug; otherwise the tool checks ~/.nuget/packages and reports HXR016 if the packages are missing.

debug builds references/Hexalith.EventStore in Debug, starts only the eventstore gateway with its Dapr sidecar, the Dapr control plane and Redis, waits for /ready, and reports the dotnet run launcher process id. Attach your debugger to the launcher's child process (ps --ppid <launcher-pid> -o pid,args). Stay attached until you finish, then stop the run with down. See CONTRIBUTING.md and the Platform README for the full prerequisites.

debug does not print the run id: it is the file name of the run state <runId>.json under ${XDG_DATA_HOME:-$HOME/.local/share}/hexalith-builds/g4-runs/ on Linux. Inspect the state files and select the one whose projectProcessIds contains the launcher id reported by this debug invocation. Confirm its manifestHash matches sha256sum references/Hexalith.EventStore/module/hexalith.module-manifest.v2.json (ignoring hexadecimal letter case), then use its runId. File modification time alone cannot identify your run. When an earlier run used the same manifest, down --manifest refuses with HXR024; add --run-id <runId>. An explicit --run-id is not cross-checked against the manifest, so verify both fields before stopping it.

This repository's own src/Hexalith.EventStore.AppHost serves only this repository's own tests. A run of it is never evidence that EventStore runs in the Platform composition.

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

Concepts

Guides

Reference

Community

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.

Bounded aggregate generation staging

DomainProjectionRebuildPlan.StagedOperations carries disjoint, create-only, nonexpiring generation values prepared without side effects. After all handlers prepare successfully, the dispatcher persists these through ReadModelGenerationStaging in resumable groups below the normal batch limits, then coordinates only the canonical authority operations. Domain pointers must select the generation only in that final commit and retain optimistic concurrency and erasure protections. A staged generation alone grants no read authority.

The dispatcher constructs and validates the complete canonical batch, including guarded ownership, before staging any generation. Every generation group is validated before the first storage write. Malformed combined plans therefore leave no staged values. Staging storage failures preserve their structured SDK retryable or indeterminate outcomes in both ordinary and streamed rebuild routes; preparation exceptions do not escape the dispatch outcome protocol.

Generation staging retains its default 512-KiB canonical-manifest and 32-operation group limits. An additive explicit byte-budget overload and DomainProjectionRebuildPlan.GenerationStagingMaxCanonicalManifestBytes support previously accepted larger individual immutable values, capped at the unchanged 1-MiB hard recovery ceiling. Conservative group partitions stay unchanged when all values already fit, preserving earlier staging identities on retry. All groups are measured with base64 encoding and scope overhead and preflighted against effective store limits before the first write.

IReadModelRecoveryScopeStore.SettleRecoveryScopeAsync finishes registered committed attempts and releases proven terminal registrations for one exact aggregate. It preserves Prepared work, including guarded rebuilds, and never uses erasure retirement for ordinary delivery recovery. Discoverable enrollment performs this settlement before adding another active registration. Both store profiles retain matching participant counts, terminal fences and content-free manifest barriers; all discoverable batches obey the hard recovery limits even when guarded ownership permits RetainManifestForRecovery=false.

Product Compatible and additional computed target framework versions.
.NET net10.0 is compatible.  net10.0-android was computed.  net10.0-browser was computed.  net10.0-ios was computed.  net10.0-maccatalyst was computed.  net10.0-macos was computed.  net10.0-tvos was computed.  net10.0-windows was computed. 
Compatible target framework(s)
Included target framework(s) (in package)
Learn more about Target Frameworks and .NET Standard.

NuGet packages

This package is not used by any NuGet packages.

GitHub repositories

This package is not used by any popular GitHub repositories.

Version Downloads Last Updated
3.128.2 64 10/25/2026
3.128.1 42 10/25/2026
3.128.0 55 10/25/2026
3.127.0 187 10/23/2026
3.126.1 261 10/21/2026
3.126.0 267 10/18/2026
3.125.1 176 10/18/2026
3.125.0 82 10/18/2026
3.124.0 228 10/16/2026
3.123.0 109 10/16/2026
3.122.0 105 10/14/2026
3.121.0 125 10/14/2026
3.120.0 273 10/10/2026
3.119.0 118 10/9/2026
3.118.1 87 10/9/2026
3.118.0 116 10/9/2026
3.117.1 188 10/8/2026
3.117.0 114 10/8/2026
3.115.0 124 10/7/2026
3.114.0 99 10/5/2026
Loading failed