Distributed applications made with Microsoft Orleans (& Dapr) and Event Sourcing using Sekiban

Distributed application made with Microsoft Orleans (&Dapr) and Event Sourcing. We build event sourcing and CQRS Framework with C#, it's called Sekiban. It is OSS, and easily develop with LLM agent with VS Code. I would like to introduce how this would improve productivity.

https://www.youtube.com/watch?v=n5ie6XBdlL8

Transcript

1. Distributed applications made with Microsoft Orleans (& Dapr) and Event Sourcing using Sekiban J-Tech Creations Inc. Tomohisa Takaoka August 11, 2025 (On .NET Live) #dotNET
2. Introduce Myself Tomohisa Takaoka X: @tomohisa GitHub: @tomohisa Works at: J-Tech Creations, Inc. J-TECH JAPAN, INC. JTS Group CTO: Small and Medium Enterprise Web application developer and architecture consultant. Microsoft MVP for Developer Technologies from Nov 2024- OSS: Sekiban - Event Sourcing and CQRS Framework. ResultBox - Railway Oriented Programming Library. 2 / 30
3. Agenda 1. Introduction 2. Foundations (Event Sourcing & Actor Model) 3. Architecture & Deployment 4. AI Productivity (MCP) 5. Dynamic Consistency Boundary 6. Demo & Summary 3 / 30
4. 1. Introduction 4 / 30
5. 1-1. Agenda & Quick Poll Please Join this Realtime Survey: Used Event Sourcing in production? Familiar with Actor model? Tried AI coding with your own framework? https://ondotnetlive0811.azurewebsites.net/qu estionair/519STQ http://bit.ly/3HuTaBp 5 / 30
6. 1-2. Sekiban Development Timeline (-2025) -2022: MVC and Fat Controller to DDD and clean architechture, database heavy system. 2022–2024: Single-server Event Sourcing (thread-based consistency) December 2023: OSS Release Feb 2025: Orleans integration (virtual actors solve concurrency + scale) May 2025: Dapr (C#) runtime option added Jul 2025: Dapr TypeScript implemented. Aug 2025: Dynamic Consistency Boundary (in active development) Enablers: Rapid LLM agent iteration (Copilot, Claude Code, Cline) + functional core. 6 / 30
7. 2. Foundations (Event Sourcing & Actor Model) 7 / 30
8. 2-1. Event Sourcing Event Sourcing is... “Event Sourcing is an architectural design pattern where changes that occur in a domain are immutably stored as events in an append-only log. This provides a business with richer data as each change that occurs within the domain is stored as a sequence of events which can be replayed in the order they occurred. This means you’re able to see more than just the current state of your domain - you can see what lead up to the current state.” Kurrent (EventStore) Blog 8 / 30
9. Client Command Model Query Model Command Handler Event Store Materialized View Event Projector Projection CQRS & Event Sourcing 2-2. CQRS Commands express intent: validate invariants → emit events (append-only log) Events as truth: projections shape task‑specific read models Separation of concerns: write = invariants & event emission / read = representation & performance Aggregate boundary: unit of consistency & concurrency; add projections without changing write logic Benefits: temporal queries, horizontal read scale, simpler mental model 9 / 30
10. 2-3. Functional ES Pattern (Determinism) Pure primitives: Decide(State, Command) → Events | Error Evolve(State, Event) → State Railway / Result pattern for composable validation Event naming: past tense domain language Why it matters: Deterministic small surface → AI can safely generate & humans review quickly. 10 / 30
11. 2-4. Challenge: Early Sekiban Without Actor Model Simple in-process thread control only – no guaranteed serialization per aggregate Two concurrent actions on the same aggregate could interleave → inconsistent decisions / lost updates Scale-out (multiple instances) made coordination harder: no built-in ownership → duplicate or conflicting writes Throughput ceiling: fear of races discouraged horizontal scale Needed a runtime that gives per-aggregate single-threaded execution + location transparency. Enter the Actor Model (Orleans grains) to naturally enforce one-at-a-time command processing per aggregate. 11 / 30
12. Actor Users Users Users Applicatio Server 1 Actor Actor Actor Actor Actor Applicatio Server 2 Actor Actor Actor Actor Actor Model Message Message Message 2-5. Actor Model Basics Each actor (grain) encapsulates state & behavior Single-threaded message processing per actor → no locks Location transparency & activation on demand (virtual actors) Natural horizontal scale across cluster Result: Concurrency correctness by construction at aggregate boundary. 12 / 30
13. 2-6. Why Orleans (& Dapr) for Sekiban Virtual Actor Model Simplify Actor Generation. Very similar programming model with regular Object Oriented Programming. Orleans advantages Automatic grain lifecycle & placement Built-in persistence & streaming options Dapr complements Sidecar building blocks (state, pub/sub, bindings) Polyglot & portability path (C# → TypeScript) Sekiban Can Share same domain code for both Dapr and Orleans Projects Pluggable runtime choices with same functional ES core. 13 / 30
14. 2-6 DEMO Start Orleans and Dapr Sekiban with dotnet new. dotnet new install Sekiban.Pure.Templates dotnet new sekiban-orleans-aspire -n MyOrleans dotnet new sekiban-dapr-aspire -n MyDapr Show event sourcing code sample Run with Aspire Locally 14 / 30
15. 3. Architecture & Deployment 15 / 30
16. Admin Web App Service / Blazor App Service / Blazor Client Web Backend App Service Clustoring State Streaming Cosmos DB Cosmos DB Azure Event Hub Streaming State Table Storage Events Cosmos DB Realtime Data Azure SignalR VNet Application Insights Log Analitics Workspace App Service can scale out KeyVault connection information 3-1. Sekiban Architecture (Layers) Design Goals: Explicit & minimal abstractions Replaceable store & runtime adapters Deterministic event pipeline 16 / 30
17. 3-2. Deployment Path Local Dev: .NET Aspire orchestration (Postgres + services) Azure Options: App Service (simplest hosting) Azure Container Apps w/ Dapr sidecars Bicep IaC for reproducible infra Storage Selection State Store: Use Orleans/Dapr persistence (Redis, Cosmos, Blob Storage, Table Storage etc.) Event Storage: Managed by Sekiban. (Azure Cosmos DB / Postgres / Dynamo (under development)) Pub/Sub Infrastracture: Use Orleans/Dapr integration. (Azure Service Bus / Event Hub / Kafka) 17 / 30
18. 3-3. Deployment Demo Show template deploy code and how to. Try to run depoy command. (if possible) 18 / 30
19. 4. AI Productivity 19 / 30
20. 4-1. Event Sourcing and Actor Model fit for AI Coding. "Regret-Free" Architecture for AI Era AI Challenge: Fast code generation + hard to track/rollback changes Solution: Event Sourcing + Actor Model Event Sourcing: Complete traceability, safe rollbacks, no data delete or erace by update. Story based event sequence. Actor Model: Linear scalability, cost-effective growth Result: AI-safe development, start under $50/month, scale naturally Blog Post:Designing Systems for the AI Coding Revolution: Achieving Regret-Free Architecture with Event Sourcing and the Actor Model 20 / 30
21. 4-2. MCP: context management helper. LLM has good concept about event sourcing, cqrs and actor model but not for the specific library implementation. Before MCP: 600–1000+ line instruction files (≈35K tokens), stale API docs, high costs MCP Server Solution: Lightweight SSE server (C#) exposing: GetDocumentNavigation / GetAllDocuments / GetDocument SearchDocumentation (keyword) / AskQuestion (Azure OpenAI) can use Context 7 as well. Flow: Agent → (asks only what it needs) → MCP → targeted markdown → Code Result: On-demand, granular, up-to-date knowledge retrieval 21 / 30
22. 4-3. AI Workflow: Practices & Gains Patterns improving reliability: Task & design files (scaffold context explicitly) Summarization-first (compress domain before coding) Functional constraints: command → events only Separation of the conscern with CQRS. Small surface; no hidden magic classes Dev Experience Gains: Reduced hallucinated APIs Faster "first correct compile" cycles Easier review (pure Decide/Evolve functions) 22 / 30
23. 5. Dynamic Consistency Boundary 23 / 30
24. 24 / 30 5-1. Dynamic Consistency Boundary (DCB)
25. 5-2. Dynamic Consistency Boundary (DCB) Problem: Some business rules need multi-aggregate atomicity without global locks. Concept: Declaratively form a temporary boundary; commit set of events atomically if all constraints satisfied (tag / query-based selection). Benefits: Avoid complex sagas for tight consistency bursts; retain ES audit & replay. Status: Active development (alpha target this month) – https://dcb.events/ 25 / 30
26. 6. Summary 26 / 30
27. 6-1. Designing for Humans & LLMs Principles applied: Deterministic pure functions at core Explicit naming & past tense events Narrow, stable file layout (discovery friendly) Focus on thin part and build complex feature. 27 / 30
28. 6-2. Roadmap & Contribution Near-Term: 1. DCB alpha & feedback loop 2. Additional storage: Dynamo, IndexedDB (WASM) 3. TypeScript + Cloudflare Durable Object 4. Enhanced MCP: embeddings + diff-aware sections 5. Event Driven improvement. How to contribute: Star repo, try template, open issues, share use case. 28 / 30
29. 6-3. Summary Recap Triad: (Actor Model + Event Sourcing) → Scalable, auditable core Functional patterns → Deterministic & AI-friendly MCP workflow → Reduced friction & drift DCB → Extends consistency beyond single aggregate Takeaway: Design architecture & tooling for both human cognition and machine retrieval. 29 / 30
30. 6-4. Reference / Thank You GitHub: https://github.com/j-tech-japan/sekiban Docs MCP Endpoint: https://sekiban-doc-mcp.azurewebsites.net/sse Blog: https://tomohisa.hashnode.dev/ DCB: https://dcb.events/ X / GitHub: @tomohisa J-Tech Creations, Inc.