[Event Sourcing] Building an Application Fast Using the Event Sourcing Pattern with Sekiban DCB and AI

A developer built a library management application using the Sekiban DCB Decider template with event sourcing, completing the full implementation in under an hour with the help of Codex and GPT-6 Astra. The AI was instructed to follow existing Student, ClassRoom, and Enrollment sample implementations as the standard, and the resulting app supports registering, borrowing, and returning books with a Blazor UI, PostgreSQL storage, and concurrency verification.

In this article, we will build an event-sourced application using Sekiban DCB and AI. Along with implementing the UI and APIs, we will check whether the application maintains consistency when multiple operations happen at the same time. For this project, I used Codex × GPT-6 Astra . The Sekiban DCB Decider template includes sample implementations that we can use as references when giving instructions to AI. These samples cover the full flow from the UI to APIs, business rules, and event persistence. We will explore how far we can take feature development and verification with AI by following these existing implementations. As an example, we will build a simple library management application that supports registering, borrowing, and returning books. We will use PostgreSQL for storage and create a basic Blazor UI to try out the APIs. The sample code is available here: BookManagement sample on GitHub https://github.com/kdaigo/SekibanSamples/tree/main/BookManagement First, run the following commands to create a project from the template: dotnet new install Sekiban.Dcb.Templates dotnet new sekiban-dcb-decider -n BookManagement You can also find instructions for getting started with the Decider template in the Quick Start on the official website https://www.sekiban.dev . For this project, I used the .NET 10 SDK and Linux containers in Docker Desktop. The UI was built with Blazor. The generated project already included samples for Student, ClassRoom, and Enrollment: We will ask AI to implement new features using these samples as references. The detailed business requirements, consistency rules, and verification scenarios are available in docs/spec.md in the sample code. Below is an excerpt from the instructions I gave AI to keep the implementation consistent with the existing samples: Before you start implementing, read the existing Student, ClassRoom, and Enrollment implementations from end to end, including the UI, APIs, commands, Deciders, events, states, and queries. Treat these implementations as the standard for this project. Rather than introducing a new design or coding style, implement the library management features by adapting similar existing code. If the existing code uses multiple approaches, choose the one closest to the business operation you are adding. Do not introduce custom helpers, new abstractions, or shorthand syntax. Only if the existing approach cannot meet the requirements, explain why, propose a change, and ask for confirmation before proceeding. The entire implementation took less than an hour, including reviewing the existing code, implementing the features, building the project, running integration and concurrency tests against a real PostgreSQL database, and checking and fixing the UI. In this template, business rules live in Deciders associated with events and states. Their main responsibilities are Validate , which checks whether an operation is allowed, and Evolve , which applies an event to a state. Below is an excerpt from the borrowing logic we implemented. Book represents the book being borrowed, User represents the borrower, and Loan represents a single loan. If the book is already on loan, another borrowing attempt is rejected. When the borrowing event is applied, the resulting state stores the LoanId and UserId. public static class BookBorrowedDecider { public static void Validate this BorrowedBookState state { throw new InvalidOperationException $"Book {state.BookId} is already borrowed" ; } public static BorrowedBookState Evolve this AvailableBookState state, BookBorrowed borrowed = new state.BookId, state.Name, borrowed.LoanId, borrowed.UserId ; } The Handler coordinates state retrieval and validation, then returns an event if validation succeeds. The Decider itself does not need any code for connecting to PostgreSQL. php flowchart LR UI Blazor UI -- API API API -- H Command Handler H -- V State retrieval and Decider validation V -- E Event creation E -- S Conflict detection and persistence by Sekiban S -- P Projector / List projection P -- Q Query Q -- UI In this project, AI implemented the new business rules using the same Decider structure as the existing code. Keeping the code structure consistent as features are added also makes it easier for developers to know where to look for business rules. This is where I found the approach particularly useful for AI-assisted coding. Checking the current state alone does not solve concurrency problems. Two requests can read the same state before either updates it, and both can conclude that the operation is allowed. For example, if two users try to borrow the same book at almost the same time, both requests might read its status as “available” before it changes. Similarly, if one user borrows different books at the same time, each request might appear to be within the borrowing limit, while the combined result exceeds it. This is where DCB, or Dynamic Consistency Boundary , comes in. It uses tags to define which entities must remain consistent together for a particular operation. Sekiban DCB provides optimistic concurrency control based on these tags. Our borrowing event has the following structure: public record BookBorrowed Guid LoanId, Guid BookId, Guid UserId, DateTime BorrowedAt : IEventPayload { public EventPayloadWithTags GetEventWithTags = new this, new LoanTag LoanId , new BookTag BookId , new UserTag UserId ; } We attach three tags—Loan, Book, and User—to a single fact: a book was borrowed. Each is defined as a consistency tag, and the Handler reads and validates the corresponding state. | Entity to check | Rule to enforce | |---|---| | Book | Prevent the same book from being loaned out twice at the same time | | User | Keep the user within the borrowing limit, even when requests involve different books | | Loan | Identify each loan and check for duplicates and whether it has been returned | Sekiban handles the concurrency checks that determine whether the events can be saved based on the state we read. The application returns an error for a request that encounters a conflict. The key is deciding which business conditions to validate and which entities to include in the consistency boundary. Adding tags alone does not automatically enforce arbitrary business rules. We define those rules explicitly in the Deciders and Handlers, then let the framework detect conflicts when saving events. The UI is a simple interface for trying out the APIs. The screenshots below show it with sample data prepared for this article The UI was originally built in Japanese. The screenshots below have been edited to show the labels and sample data in English for this article. . The book list shows each book’s status. The button for removing a book from the catalog is disabled while the book is on loan. On the borrowing and returns screen, you can select a user and a book to create a loan. Loan records remain in the history after the books are returned, and the Return button is disabled for those records. The API’s business rules also check whether each operation is allowed. To verify that consistency was maintained, we tested the following scenarios: For every scenario, we sent multiple requests at almost the same time to an API connected to a real PostgreSQL database. We confirmed that operations violating the business rules were rejected and that the related states remained consistent. By asking AI to add features that followed the existing samples, we were able to implement and verify the application in a short time. Letting Sekiban handle conflict detection and persistence also allowed us to focus on implementing the business rules. I hope this article encourages you to try building an event-sourced application with Sekiban DCB and AI.