What the book is.
The book is a practitioner guide to Event Sourcing and CQRS, 448 pages at 7 by 10 inches, across 18 chapters, with 72 diagrams and 79 code listings, in paperback and hardcover. Both editions are scheduled for November 1, 2026, on Amazon.
The premise is that these patterns are usually explained at a level that survives a conference talk and collapses on contact with production. Concurrency, versioning, projection rebuilds, and the operational surface get a paragraph each, if that. This book was written the other way around: every pattern in it was built and run first, then written about.
It is deliberately opinionated about where these patterns do not belong. Event sourcing applied to everything is a failure mode, and a chapter that tells you when to keep a boring CRUD table earns more trust than one that does not.
The reference implementation is public.
The companion repository is on GitHub under the MIT licence, tagged v1.0.0, built on .NET 10 and C# 14. It is a production-grade implementation rather than a sample, and it is licensed so you can adapt it inside commercial work.
It models an order-management domain across five bounded contexts, event-sourced end to end. Five aggregates are rebuilt from events, two process managers are themselves event-sourced on their own streams with compensation branches, and eight projections maintain read models over a mix of relational tables and JSONB.
Four hosts run against it: a Blazor Server user interface, a JSON API, a workers host carrying projections and the outbox, and an administration console. Role-based authorisation and tenant isolation run through all of them. Fifty-three architecture decision records carry the reasoning behind the shape.
Four event stores, one interface.
The part most implementations skip is portability. Four event stores sit behind a single interface as first-class peers, and all four pass the same contract test suite, so moving between them is a configuration change rather than a rewrite.
That matters for a modernization buyer more than it looks. It means the patterns in the book are not welded to one vendor, and that a system built this way can start on the database you already run and move later without discarding the domain model.
Who it is for.
Engineers and architects who have read the pattern descriptions and want to see the whole thing assembled, with the awkward parts included. It assumes you can read C# and does not assume you have run an event-sourced system before.
It is also written for the person who has to decide whether any of this is warranted. A large part of the value is the material on when a rich domain model, a read model, or a plain CRUD table is the right answer, so that event sourcing is chosen where it pays and avoided where it does not.
Teams with an existing system are the other reader. The migration chapters are about moving that system onto an event store one bounded context at a time. Looking at your system, rather than the sample, starts with the free 1-hour consultation.
Status, honestly stated.
The paperback and the hardcover are scheduled for November 1, 2026, self-published on Amazon. This page will add the product links when the listings are live. There is no preorder here.
The reference implementation is public now. If you are deciding whether event sourcing belongs in a system you already operate, book the free 1-hour consultation. When the system warrants a deeper look, the next paid step is a fixed-scope Legacy Software Assessment. The fee is quoted on that call and is creditable toward a later modernization project.
Four event stores, all passing the same contract suite.
| Event store | How it is accessed | What it demonstrates |
|---|---|---|
| PostgreSQL | Hand-rolled over Npgsql | An append-only store on a database most teams already run, with commit-ordered global position. |
| SQL Server | Hand-rolled over Microsoft.Data.SqlClient | The same contract on the Microsoft stack, for shops that will not add a new database. |
| KurrentDB | gRPC client | A purpose-built event store, for comparison against the hand-rolled adapters. |
| DynamoDB | Conditional writes | Optimistic concurrency without a relational engine, and what that costs. |
Common questions
Has the book been published?
The paperback and the hardcover are scheduled for November 1, 2026, self-published on Amazon. The product pages are not live yet. This page will link them when they are.
Can I read it now?
You can read and run the reference implementation today. The paperback and the hardcover follow on November 1, 2026.
What licence is the reference implementation under?
MIT. It is intended to be cloned, run, read, and adapted, including inside commercial work, without asking permission.
Do I need the book to use the code?
No. The repository carries its own documentation and fifty-three architecture decision records explaining why it is shaped the way it is.
Which event store should I use?
The one you already operate, in most cases. The implementation exists partly to show that the domain model does not have to change when that answer changes.
Does Legacy to Modern do this work for clients?
Yes, where it is warranted. Event sourcing belongs inside a bounded context that needs it, not across a whole system. The first conversation is a free 1-hour consultation. A fixed-scope Legacy Software Assessment is how we establish which parts of your system warrant it. The fee is quoted after that call and is creditable toward a subsequent project.
Not sure where to start?
Start with a fixed-scope Legacy Software Assessment: a read-only review of your application’s source, database, configuration, logs, and architecture, ending in findings with evidence and a written recommendation. Quoted after the free 1-hour consultation; creditable toward a subsequent modernization project.