BOOK

Event Sourcing & CQRS:
the manuscript is finished, and the code is already public.

Thomas Jaeger has completed a 452-page practitioner guide to Event Sourcing and CQRS, built on a reference implementation that runs. The manuscript is with publishers. The code behind it is public, MIT licensed, and available to clone today.

In short. The book is written and in submission, so there is no publication date to announce yet. The reference implementation it is built on is already public under the MIT licence, and you can read and run it without the book.

What the book is.

It is a practitioner guide to Event Sourcing and CQRS: 452 pages across 18 chapters, with 72 custom diagrams and 79 code listings. The manuscript is complete and voice-uniform, not a work in progress.

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.

Browse the reference implementation on GitHub →

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.

Status, honestly stated.

The manuscript is complete and in submission. No publisher has been announced, no publication date exists, and nothing on this page should be read as either. When there is a contract to name, this page will name it.

The reference implementation is not waiting on any of that. It is public now, and it is the part you can evaluate today. If you want to be told when the book has a date, the fastest route is to reach out directly; there is no mailing list to join.

Four event stores, all passing the same contract suite.

Event storeHow it is accessedWhat it demonstrates
PostgreSQLHand-rolled over NpgsqlAn append-only store on a database most teams already run, with commit-ordered global position.
SQL ServerHand-rolled over Microsoft.Data.SqlClientThe same contract on the Microsoft stack, for shops that will not add a new database.
KurrentDBgRPC clientA purpose-built event store, for comparison against the hand-rolled adapters.
DynamoDBConditional writesOptimistic concurrency without a relational engine, and what that costs.

Common questions

Has the book been published?

Not yet. The manuscript is complete and in submission with publishers. There is no publication date, and no publisher is named here until a contract exists.

Can I read it now?

Not the manuscript. The reference implementation it is built on is public today under the MIT licence, and it stands on its own without the book.

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, and an assessment is how we establish which is which.

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.