DEV Community: kairi

[Event Sourcing] Running an Existing C# Business Model on Wasm with SekibanWasmRuntime

kairi — Wed, 16 Sep 2026 06:05:09 +0000

In the previous article, we created a C# application using Sekiban DCB to handle students, classes, and class enrollment. This time, we will try running that application with SekibanWasmRuntime, which allows Sekiban to run with Wasm (WebAssembly).

In this article, we will run a project written in C# as Wasm. SekibanWasmRuntime currently provides primary support for C# and Rust, while Go, TypeScript, MoonBit, and Swift are also available as experimental implementations.

The sample code used in this article is available here.

1. Roles of Sekiban and Wasm

Sekiban is an event sourcing framework that provides a mechanism for storing events that occur in an application and building the current state from those events.

Wasm is an executable format produced by compiling code. In this example, SekibanWasmRuntime running on the server loads and executes the Wasm file. The application contains the business code related to students, while the Runtime provides the environment for executing that code and the mechanism for storing events.

2. What Runs in Wasm

The architecture used in this example is as follows.

Scalar / PowerShell
    ↓ 
API
    ↓ ISekibanExecutor
RemoteSekibanExecutor
    ├── Executes existing Command handlers on the API side
    └── Requests state retrieval, event commit, and Query execution over HTTP
            ↓ 
SekibanWasmRuntime
    ├── Executes the Projector and list Query in Wasm
    └── Stores events in PostgreSQL

Command handlers run on the API side, while the Projector that builds state from events and the student list processing run as Wasm inside the Runtime.

When a student is created, the process works in the following order.

The HTTP endpoint receives the request to create a student.
The existing Command handler runs on the API side and creates an event according to the business rules.
The API requests the Runtime to store the event through the Remote connection.
The Runtime stores the event, and the Projector in Wasm applies the event when state is retrieved or the list is updated.
The retrieval API can then be used to check the state of the created student or the student list.

The business logic remains unchanged, but we need to add an entry point for calling Wasm, type registration, and API connection settings. The entire Web API and all Commands do not run inside Wasm.

For this example, I used the following versions.

Component	Version
.NET	10
Sekiban.Dcb	10.19.0
Sekiban.Dcb.WasmRuntime.Aspire	1.0.0-preview.6
Sekiban.Dcb.WasmRuntime.Remote	1.0.0-preview.6
Runtime container	1.0.0-preview.3

The NuGet packages and the Runtime container use different version series.

3. What Was Added or Changed

To reuse the existing business logic, I added the Wasm entry point and execution environment.

The official C# Wasm template specifies using Docker when building Wasm on Windows or macOS. Following this procedure, we prepare the build environment for compiling C# to Wasm inside Docker. The generated Wasm file is then loaded and executed by SekibanWasmRuntime.

Added or changed item	Purpose
Wasm project	References the existing EventSource and builds it as Wasm
Wasm entry point and type registration	Connects the Runtime to the existing Projector and provides the type information required for ahead-of-time compilation
manifest	Tells the Runtime which Wasm, events, Projectors, and Queries are associated with each other
Build scripts	Build Wasm inside Docker
AppHost settings	Start the Runtime container and a dedicated PostgreSQL instance
Remote connection for the API	Replaces the `ISekibanExecutor` implementation with `RemoteSekibanExecutor`

The Wasm project references the existing code as follows. The following code snippets show the main settings and implementations that were added.

<ProjectReference Include="..\DCBNativeWasmProject.EventSource\DCBNativeWasmProject.EventSource.csproj" />

At the entry point called by the Runtime, we use the existing Projector.

instance.State = StudentProjector.Project(instance.State, ev);

On the API side, we register the implementation used to communicate with the Runtime.

builder.Services.AddHttpClient<RemoteSekibanExecutor>(http =>
{
    http.BaseAddress = new Uri(builder.Configuration["Runtime:BaseUrl"]!);
    http.Timeout = TimeSpan.FromSeconds(90);
});

builder.Services.AddTransient<ISekibanExecutor>(
    sp => sp.GetRequiredService<RemoteSekibanExecutor>());

With this configuration, the existing endpoints can continue calling executor.ExecuteAsync(command).

Package and Wasm Configuration

Run the following commands from the project root directory. Prepare the .NET 10 SDK and Docker Desktop beforehand. On Windows, use Git Bash, and on macOS, use a terminal. Because the build tools are provided inside Docker, you do not need to install the WASI SDK directly.

The packages added to AppHost and the API are as follows.

dotnet add ./DCBNativeWasmProject.AppHost\DCBNativeWasmProject.AppHost.csproj package Sekiban.Dcb.WasmRuntime.Aspire --version 1.0.0-preview.6
dotnet add ./DCBNativeWasmProject.ApiService\DCBNativeWasmProject.ApiService.csproj package Sekiban.Dcb.WasmRuntime.Remote --version 1.0.0-preview.6

The following settings are added to DCBNativeWasmProject.Wasm/DCBNativeWasmProject.Wasm.csproj to generate Wasm output. These are the main settings.

<TargetFramework>net10.0</TargetFramework>
<RuntimeIdentifier>wasi-wasm</RuntimeIdentifier>
<OutputType>library</OutputType>
<AllowUnsafeBlocks>true</AllowUnsafeBlocks>
<InvariantGlobalization>true</InvariantGlobalization>
<IsAotCompatible>true</IsAotCompatible>
<SelfContained>true</SelfContained>
<IlcExportUnmanagedEntrypoints>true</IlcExportUnmanagedEntrypoints>
<NativeLib>Shared</NativeLib>

The actual file also includes a package reference for NativeAOT-LLVM and linker settings that expose the functions called by the Runtime. In WasmExports.cs, type information is explicitly registered, and entry points are provided for applying events, saving and restoring state, and retrieving lists. NuGet.wasm.config specifies the package sources required for this build.

Map Wasm and Processing in the manifest

config/sekiban-manifest.json tells the Runtime which Projectors and Queries are provided by each Wasm module. The following is an excerpt related to the student list.

{
  "defaultModulePath": "/app/modules/dcb-native.wasm",
  "queryAssemblyVersion": "wasm",
  "projectors": [
    {
      "projectorName": "StudentListProjection",
      "projectorVersion": "1.0.1",
      "modulePath": "/app/modules/dcb-native.wasm",
      "abiKind": "wasi-preview1",
      "moduleVersion": "1.0.0"
    }
  ],
  "queryProjectors": {
    "GetStudentListQuery": "StudentListProjection"
  }
}

Connect the Runtime and API from AppHost

In DCBNativeWasmProject.AppHost/WasmAppHost.cs, we start the Runtime and a PostgreSQL instance. root is the absolute path to the project root.

var pg = builder.AddPostgres("wasm-postgres");
var events = pg.AddDatabase("SekibanDcb", "dcb_native_wasm_events");

var runtime = builder.AddSekibanWasmRuntime(
    "wasm-runtime",
    new SekibanWasmRuntimeOptions
    {
        ConfigDirectory = Path.Combine(root, "config"),
        ModulesDirectory = Path.Combine(root, "modules"),
        WasmModulePath = "/app/modules/dcb-native.wasm",
        EventStoreDatabase = events,
        ProjectionMode = "memory-only",
        HostPort = 5280
    })
    .WithEnvironment("SEKIBAN_WASM_POOL_SIZE", "0")
    .WaitFor(events);

memory-only is the projection mode used to build projections by applying events. The events themselves are stored in PostgreSQL. SEKIBAN_WASM_POOL_SIZE=0 is set as a workaround for an issue in this preview version where consecutive list updates could wait indefinitely. This is not a recommended value that has been evaluated for production use.

Next, we pass the Runtime URL to the API.

builder.AddProject<DCBNativeWasmProject_ApiService>(
        "wasm-api", launchProfileName: null)
    .WithEnvironment("Runtime__BaseUrl", runtime.GetEndpoint("http"))
    .WithEnvironment("ASPNETCORE_ENVIRONMENT", "Development")
    .WithHttpEndpoint(
        port: 5241, targetPort: 5241, name: "http", isProxied: false)
    .WithEnvironment("ASPNETCORE_URLS", "http://localhost:5241")
    .WaitFor(runtime);

Runtime__BaseUrl passes the SekibanWasmRuntime endpoint to the API. The API uses this endpoint to request state retrieval and event storage from the Runtime.

4. Build the Wasm File

Start Docker Desktop and move to the project root directory in your terminal. Adjust the path to match your working directory.

bash scripts/build-wasm.sh

The script uses scripts/Dockerfile.wasm-build to create a Docker image for the build, and then scripts/build-wasm-container.sh runs the following command inside the container.

dotnet publish DCBNativeWasmProject.Wasm/DCBNativeWasmProject.Wasm.csproj \
  -c Release -r wasi-wasm \
  -o artifacts/wasm/publish --configfile NuGet.wasm.config

The build result is copied to the location used by the Runtime, and wasm-tools validate is used to validate the Wasm format. When the build succeeds, a log similar to the following is displayed. The file size may change depending on the implementation.

Example output when the Wasm build completes:

[build-wasm] OK: modules/dcb-native.wasm (25282599 bytes)

Output Locations of the Build Files

The following paths are relative to the project root.

Location	Description
`artifacts/wasm/publish/DCBNativeWasmProject.Wasm.wasm`	Wasm generated by `publish`
`modules/dcb-native.wasm`	A copy of the generated Wasm file that is loaded by the Runtime
`DCBNativeWasmProject.Wasm/bin/` and `obj/`	Build outputs and intermediate files
`config/sekiban-manifest.json`	Runtime configuration created manually. This is not a build output.

The modules folder on the host is mounted into the Runtime container. Therefore, the manifest and AppHost specify /app/modules/dcb-native.wasm, which is the path inside the container.

The Wasm project used in this example is built separately from the normal solution build. Run the dedicated build script before starting AppHost.

5. Start the Application

In the same terminal, set the environment variables and start AppHost.

export ASPIRE_ALLOW_UNSECURED_TRANSPORT=true
export ASPNETCORE_URLS=http://localhost:15900
export ASPIRE_DASHBOARD_OTLP_ENDPOINT_URL=http://localhost:15901
export ASPIRE_DASHBOARD_OTLP_HTTP_ENDPOINT_URL=http://localhost:15902

dotnet run --project DCBNativeWasmProject.AppHost --no-launch-profile

These settings are for local execution. AppHost starts the dedicated PostgreSQL instance, the Runtime container, and the API.

6. Execution Results

Create a student from Scalar, and then retrieve the student using the same ID. The following is the actual response returned by the API for the request shown below. The IDs will be different each time you run it.

POST /api/students/
Content-Type: application/json

{
  "studentId": "10c8f945-8314-4631-8c3d-627dbd22934a",
  "name": "山田太郎",
  "maxClassCount": 5
}

{
  "studentId": "10c8f945-8314-4631-8c3d-627dbd22934a",
  "eventId": "01a08f5c-d51e-7cf9-9e22-ad1348d4137e",
  "sortableUniqueId": "063924708420894567502099121181",
  "message": "Student created successfully"
}

Next, retrieve the student that was created.

GET /api/students/10c8f945-8314-4631-8c3d-627dbd22934a

{
  "studentId": "10c8f945-8314-4631-8c3d-627dbd22934a",
  "payload": {
    "studentId": "10c8f945-8314-4631-8c3d-627dbd22934a",
    "name": "山田太郎",
    "maxClassCount": 5,
    "enrolledClassRoomIds": []
  },
  "version": 1
}

The student creation event is applied by the Projector running in Wasm, and we can retrieve the student's state. List retrieval and updates can also be executed from the same Scalar screen.

7. Conclusion

By using SekibanWasmRuntime, we can change the execution environment while continuing to use existing models and Projectors, as in this example, by adding a Wasm entry point and connection settings. The business logic we have already created can also be used with this architecture.

I also felt that by leaving event storage and Wasm execution to SekibanWasmRuntime, the application side can focus more on implementing the business logic: what kinds of operations the application accepts and what kinds of events those operations produce. Because the API can use the Runtime through a Remote connection, the part that calls the business processing can be separated from the part responsible for execution and storage.

Samples for Go and TypeScript are also available as experimental/reference implementations, and I am looking forward to seeing further support added in the future.

[Event Sourcing] Trying out Sekiban DCB: Implementation

kairi — Wed, 16 Sep 2026 04:50:24 +0000

Introduction

This article is a continuation of "[Event Sourcing] Trying out Sekiban DCB: Introduction". In the previous post, we covered setting up the DCB Native environment and its processing flow.

kairi

Sep 16

[Event Sourcing] Trying out Sekiban DCB: Introduction

#tutorial #eventsourcing #dcb

2 min read

Initially, features like creating a Student, fetching individual and list data, and enrolling/dropping classes are already implemented. The student's state is built from recorded events. The information a student holds includes Student ID, Name, Max Class Count, and a list of currently enrolled classes.

In this post, we will add a feature to update a student's name and their maximum class limit. The Student ID and enrolled classes will remain unchanged. Decreasing the max limit below the current number of enrolled classes will be prohibited.

When updating, we don't directly overwrite the current data. Instead, we record a StudentProfileUpdated event. A Projector then processes this event to build the updated student state.

Update Feature Specifications

Item	Specification
`StudentId`	Specifies the student to update. It is not changed.
`Name`	Required, 1 to 100 characters
`MaxClassCount`	1 to 10. Changing it to a value lower than the current enrollment count is not allowed.
Enrollment list	Keeps the contents before the update.
Non-existing student	The update is rejected.

The API receives JSON containing the student ID.

POST /api/students/update
Content-Type: application/json

{
  "studentId": "9912a519-a6f6-41fe-92bf-07b99045efff",
  "name": "John",
  "maxClassCount": 3
}

We will add the implementation in the order of Event, Decider, Command, Projector, and API.

The sample code is available on GitHub.

1. Add an Event That Represents the Update

We define the fact that the student information was updated as StudentProfileUpdated event.

using Dcb.ImmutableModels.Tags;
using Sekiban.Dcb.Events;

namespace Dcb.ImmutableModels.Events.Student;

public record StudentProfileUpdated(
    Guid StudentId,
    string Name,
    int MaxClassCount) : IEventPayload
{
    public EventPayloadWithTags GetEventWithTags() =>
        new(this, new StudentTag(StudentId));
}

The event records the target student ID, the updated name, and the updated maximum number of classes. By adding StudentTag, this event is associated with the target student.

The enrollment list is not included in the event because it is not part of this update.

2. Implement Business Rules and State Updates in Deciders

In Deciders, we implement validation based on the current state and the processing that applies the event to the state.

using Dcb.ImmutableModels.Events.Student;

namespace Dcb.ImmutableModels.States.Student.Deciders;

public static class StudentProfileUpdatedDecider
{
    public static void Validate(StudentState state, int maxClassCount)
    {
        if (maxClassCount < state.EnrolledClassRoomIds.Count)
        {
            throw new ApplicationException(
                "MaxClassCount cannot be less than the current enrollment count.");
        }
    }

    public static StudentState Evolve(
        this StudentState state,
        StudentProfileUpdated updated) =>
        state with
        {
            Name = updated.Name,
            MaxClassCount = updated.MaxClassCount
        };
}

In Validate, the updated maximum class count is compared with the current number of enrolled classes. For example, if a student is enrolled in three classes, the maximum class count cannot be changed to two.

In Evolve, the state with the contents of the event applied is returned. Only the name and maximum class count can be changed, while the student ID and enrollment list are kept unchanged.

3. Add a Command to Handle Update Requests

UpdateStudent is responsible for defining the input values and handling the processing from retrieving the state to generating the event.

using System.ComponentModel.DataAnnotations;
using Dcb.ImmutableModels.Events.Student;
using Dcb.ImmutableModels.States.Student;
using Dcb.ImmutableModels.States.Student.Deciders;
using Dcb.ImmutableModels.Tags;
using Sekiban.Dcb.Commands;
using Sekiban.Dcb.Events;

namespace Dcb.EventSource.Student;

public record UpdateStudent : ICommandWithHandler<UpdateStudent>
{
    public Guid StudentId { get; init; }

    [Required(ErrorMessage = "Name is required")]
    [StringLength(
        100,
        MinimumLength = 1,
        ErrorMessage = "Name must be between 1 and 100 characters")]
    public string Name { get; init; }

    [Range(1, 10,
        ErrorMessage = "MaxClassCount must be between 1 and 10")]
    public int MaxClassCount { get; init; }

    public UpdateStudent(
        Guid studentId,
        string name,
        int maxClassCount)
    {
        StudentId = studentId;
        Name = name;
        MaxClassCount = maxClassCount;
    }

    public static async Task<EventOrNone> HandleAsync(
        UpdateStudent command,
        ICommandContext context)
    {
        var tag = new StudentTag(command.StudentId);

        var tagState =
            await context.GetStateAsync<StudentProjector>(tag);

        if (tagState.Payload is not StudentState state)
        {
            throw new ApplicationException("Student does not exist.");
        }

        StudentProfileUpdatedDecider.Validate(
            state,
            command.MaxClassCount);

        return new StudentProfileUpdated(
            command.StudentId,
            command.Name,
            command.MaxClassCount)
            .GetEventWithTags();
    }
}

Validation	Implementation location
Name is required and has a valid length	Command attributes
Maximum class count is between 1 and 10	Command attributes
The student to update exists	Command handler
Maximum class count is greater than or equal to the current enrollment count	Decider

After Sekiban validates the Command attributes, the handler retrieves the current state of the student. If the business rule validation passes, it generates and returns StudentProfileUpdated.

Sekiban handles event persistence, so there is no need to write database persistence logic in the handler.

4. Add Update Event Handling to the Projector

Saving the event alone does not reflect the update in the student state. We add handling for the update event and Evolve to the Projector that builds the state.

For StudentProjector, which handles the state of a single student, add the following branch.

(StudentState state, StudentProfileUpdated updated)
    => state.Evolve(updated),

The processing for each event becomes as follows.

public static ITagStatePayload Project(
    ITagStatePayload current,
    Event ev) =>
    (current, ev.Payload) switch
    {
        (EmptyTagStatePayload, StudentCreated created)
            => StudentCreatedDecider.Create(created),
        (StudentState state, StudentProfileUpdated updated)
            => state.Evolve(updated),
        (StudentState state, StudentEnrolledInClassRoom enrolled)
            => state.Evolve(enrolled),
        (StudentState state, StudentDroppedFromClassRoom dropped)
            => state.Evolve(dropped),
        _ => current
    };

We also add handling for the same event to StudentListProjection, which builds the student list.

var newState = ev.Payload switch
{
    StudentCreated created
        => StudentCreatedDecider.Create(created),
    StudentProfileUpdated updated
        => currentState.Evolve(updated),
    StudentEnrolledInClassRoom enrolled
        => currentState.Evolve(enrolled),
    StudentDroppedFromClassRoom dropped
        => currentState.Evolve(dropped),
    _ => currentState
};

With this, the updated name and maximum class count are reflected in both the state of a single student and the student list.

5. Add the Update API

Add an endpoint to StudentEndpoints that receives the update Command.

group.MapPost("/update", UpdateStudentAsync)
    .WithName("UpdateStudent");

private static async Task<IResult> UpdateStudentAsync(
    [FromBody] UpdateStudent command,
    [FromServices] ISekibanExecutor executor)
{
    var execution = await executor.ExecuteAsync(command);

    return Results.Ok(new
    {
        studentId = command.StudentId,
        eventId = execution.EventId,
        sortableUniqueId = execution.SortableUniqueId,
        message = "Student updated successfully"
    });
}

The API directly receives UpdateStudent and asks Sekiban to execute it. The check for whether the student exists and the validation of the maximum class count are handled through the Command and Decider processing.

The flow from the update request to event persistence is as follows.

POST /api/students/update
    ↓
UpdateStudent
    ↓
Validate input values
    ↓
Retrieve the current student state
    ↓
Check the existence of the student
and the consistency of the maximum class count
    ↓
Generate StudentProfileUpdated
    ↓
Sekiban stores the event

When building or updating the state from the stored event, the Projector calls the corresponding Evolve.

Events Stored in PostgreSQL

Let's check the events actually stored in the database. In dcb_events, the following creation event and update event are stored. The data below was retrieved in ascending order of SortableUniqueId.

[
  {
    "ServiceId": "default",
    "Id": "01a0840a-df7f-7c43-9665-0564c61c7718",
    "SortableUniqueId": "063924518500223460000021724853",
    "EventType": "StudentCreated",
    "Payload": {
      "studentId": "9912a519-a6f6-41fe-92bf-07b99045efff",
      "name": "Student update persistence test",
      "maxClassCount": 5
    },
    "Tags": ["Student:9912a519-a6f6-41fe-92bf-07b99045efff"],
    "Timestamp": "2026-09-09T02:41:40.235475+00:00",
    "CausationId": "01a0840a-df7f-7c43-9665-0564c61c7718",
    "CorrelationId": "CreateStudent",
    "ExecutedUser": "GeneralSekibanExecutor"
  },
  {
    "ServiceId": "default",
    "Id": "01a0840a-e817-7b00-8c14-4f869aa9a78d",
    "SortableUniqueId": "063924518502423536500632865263",
    "EventType": "StudentProfileUpdated",
    "Payload": {
      "studentId": "9912a519-a6f6-41fe-92bf-07b99045efff",
      "name": "Student update persistence test updated",
      "maxClassCount": 3
    },
    "Tags": ["Student:9912a519-a6f6-41fe-92bf-07b99045efff"],
    "Timestamp": "2026-09-09T02:41:42.43232+00:00",
    "CausationId": "01a0840a-e817-7b00-8c14-4f869aa9a78d",
    "CorrelationId": "UpdateStudent",
    "ExecutedUser": "GeneralSekibanExecutor"
  }
]

For the same student ID, the name and maximum class count at the time of creation and the updated name and maximum class count remain as separate events.

When StudentProfileUpdated is applied to the state created by StudentCreated, the name becomes Student update persistence test updated, and the maximum class count becomes 3. The Projector branch and the Decider's Evolve added this time reproduce this state change.

Conclusion

By implementing the student information update step by step, I felt that I gained a deeper understanding of the event sourcing flow of "validating a change, recording it as an event, and building the state from that history," as well as the role of each process. I also thought it was very useful that persistence can be left to Sekiban, allowing us to focus on business rules and state changes.

This time, I used Codex for the implementation. Instead of asking it to implement the entire feature at once, I proceeded while checking the purpose and code of each step. Since the processing in this structure is separated by responsibility, it worked well with this kind of implementation through dialogue, and I was able to implement the feature while building up my understanding step by step.

[Event Sourcing] Trying out Sekiban DCB: Introduction

kairi — Wed, 16 Sep 2026 02:51:17 +0000

Introduction

While researching ways to ensure data consistency using NoSQL in systems with frequent reads and writes, I became interested in Event Sourcing and CQRS. During this process, I found a framework called Sekiban, which is designed for Event Sourcing/CQRS, and decided to try it out.

Sekiban - Event Sourcing / CQRS Framework

Sekiban is an open-source Event Sourcing and CQRS framework for .NET using C#. Store events in Azure Cosmos DB, PostgreSQL, or AWS DynamoDB.

sekiban.dev

What is Sekiban DCB?

According to the official website, Sekiban is defined as:

"An open-source Event Sourcing and CQRS framework for .NET. It stores not just the current state, but all changes as immutable events."

Within this framework, Sekiban DCB is an Event Sourcing framework that implements a Dynamic Consistency Boundary (DCB). It records all events in a single global stream.

Looking at their documentation, they offer three approaches: DCB Native, DCB Wasm, and Sekiban Cloud (which seems to be still in development and not yet released). For this guide, I will run it using Native C#.

Development Environment & Setup

Prerequisites:

OS: Windows 11 Pro
Environment: ASP.NET development environment ready

If your environment is set up, you can create a new project with just a few commands:

# Install the Sekiban DCB templates
dotnet new install Sekiban.Dcb.Templates

# Create project with Decider pattern
dotnet new sekiban-dcb-decider -n MyApp

# Run with Aspire
dotnet run --project MyApp.AppHost

Running the last command will start the Aspire dashboard. The official DCB documentation uses a Student and Class relationship as an example. The default project automatically includes sample code for registering students and enrolling them in classes.

Project Structure

Here is a quick overview of the created project structure:

Project	Purpose
`DCBNativeProject.AppHost`	Manages dependent services, connections, ports, and startup order.
`DCBNativeProject.ApiService`	Handles API routing and authentication.
`DCBNativeProject.EventSource`	Contains Commands, Handlers, Projectors, and data search processing.
`DCBNativeProject.ImmutableModels`	Defines Student/Class events, Tags, State, and Deciders.

To give you an idea of how it works, here is the flow for creating and getting a student record.

Creating a Student

Read the incoming JSON and convert it to a CreateStudent command.
Execute the command using ExecuteAsync.
Generate a "StudentCreated" event (in this sample, it only uses a StudentTag).
The framework saves the event to the database.
Return the result to the user.

Retrieving a Student

Receive the Student ID and find the target student using the StudentTag.
Define the expected data state using a StudentProjector.
Call GetTagStateAsync to restore the current state from the past events.
Return the result to the user.

Conclusion

As you can see, database saving operations are completely handled by the framework. I was able to save and load events without worrying about the database code at all.

Next time, I plan to add more Entities and try out some different event registrations!