# laravel-event-sourcing wants you to think in aggregates, projectors and reactors > Spatie's package gives a Laravel application event sourcing with three named pieces: aggregates that decide, projectors that build read models, and reactors that react. The README is short and points at documentation and three example apps, which is the honest shape of a package that is an entry point rather than a framework. **spatie/laravel-event-sourcing** — The easiest way to get started with event sourcing in Laravel - Repository: https://github.com/spatie/laravel-event-sourcing - Website: https://docs.spatie.be/laravel-event-sourcing - Stars: 919 · Forks: 176 - Language: PHP - License: MIT - Published: 2026-10-20 · Updated: 2026-10-20 · Language: en - Canonical page: https://hysenlabs.com/projects/spatie-laravel-event-sourcing ## Three vocabulary words and the questions they answer This package aims to be the entry point to get started with event sourcing in Laravel. It can help you with setting up aggregates, projectors, and reactors. Those three nouns are the entire conceptual surface, and the README assumes you either know them or will go read about them. If you have never worked with event sourcing, or are uncertain about what aggregates, projectors and reactors are, it points you to the getting familiar with event sourcing section in the docs. That framing tells you what this is. It is not an opinionated application framework that wraps Laravel in an event-sourced world. It is a set of Laravel-native building blocks, and the design decisions stay yours. The three questions the README offers for deciding whether event sourcing fits are more useful than the feature list, because they are about your domain rather than about the package. The first is whether your app needs to make decisions based on the past. The second is whether you have auditing requirements, phrased as whether the reason why your app is in a certain state is equally as important as the state itself. The third is whether you foresee a reporting need in the future but do not know yet which data you need to collect for those reports. That third question is the one that pulls people in who are not building a bank. Event sourcing is a way of capturing data you did not think to capture, and if you have no reason to want history beyond the current state, the storage cost buys you nothing. ## Three versions of the same banking app, and what they teach The README offers example apps, and the choice of them is the best teaching signal in the document. In each of them you can create accounts and deposit or withdraw money. The three are Larabank built traditionally without event sourcing, Larabank built with projectors, and Larabank built with aggregates and projectors. Read in order, they show the same feature implemented three ways. The traditional version is what the application would look like with ordinary Laravel models and no history. The projector version keeps an event log and derives read models from it, without the aggregate root deciding anything. The third adds aggregates, where the model itself owns the rules and the state changes come out of recorded events. That progression is the actual argument for the package. It lets you see the cost of each step. The traditional version is the easiest to write and the hardest to change later, because the past is gone. The projector version captures history without introducing the domain logic layer. The aggregate version is the one that makes the past authoritative, and it is also the one that costs the most to retrofit. For someone evaluating whether to adopt this, the second example is probably the most useful. It shows what you get from adding event sourcing without also committing to aggregates, which is often the right first step for an application whose reporting needs are still forming. The example apps live in separate repositories under the spatie organisation, and the README describes them as apps where you can create accounts and deposit or withdraw money, which is a small enough domain to hold in your head while you read the code. ## Installation is documented off the README, in the v7 docs site The README does not contain an install command. It says you can find installation instructions and detailed instructions on how to use this package at the dedicated documentation site. ``` https://spatie.be/docs/laravel-event-sourcing/v7/introduction/ ``` The version marker in that URL is worth noticing, because the package is on a major version line of its own. The documentation is versioned by package release, not by Laravel release, so the v7 in the path corresponds to the 7.x line of the package rather than to anything about Laravel itself. The repository itself gives you the standard Laravel package surface. There is a config/ directory for the package configuration, a database/ directory for the migrations that create the stored events, stubs/ for the publishable stub files that generate your aggregate and projector classes, a docs/ directory, and tests/ with a phpunit.xml.dist and a psalm.xml for static analysis. There is also a .php_cs.php, which is the older coding standards configuration file, and a UPGRADING.md at the root. The stubs directory is the part that tells you how the package expects you to work. The published stubs are what generate the class skeletons for your own aggregates and projectors, so the package imposes its conventions on your file layout through code generation rather than through abstract base classes you have to discover. The CHANGELOG.md is at the root as well, and the README asks you to see it for more information on what has changed recently. ## It supersedes laravel-event-projector with the same API Migration history is short but worth knowing, because a package with the same API as its predecessor is an unusual and useful thing to find. The package supercedes laravel-event-projector. It has the same API, and the README says upgrading from laravel-event-projector to laravel-event-sourcing is easy, with an upgrade guide in UPGRADING.md. Same API means the concepts did not change, only the framing and the naming. If you have seen the older package, the mental model transfers directly. If you are starting fresh, the names in this README are the ones to learn. That also tells you something about the package's stability. A superceding package with an unchanged API and a documented upgrade path means the concepts have settled. That is a point in favour of adopting it rather than against, since the churn that usually makes event sourcing packages risky is concentrated in the API surface and here it is explicitly frozen. The package also credits its inspirations. The aggregate root functionality is heavily inspired by Frank De Jonge's EventSauce package, and the README thanks Dries Vints for giving lots of valuable feedback while the package was being developed. Freek Van der Herten is credited first in the contributors list. The docs also point to a course on event sourcing in Laravel, which tells you the intended audience includes people who want structured teaching rather than just an API reference. ## Postcardware, MIT, and a security contact that is not the issue tracker The licence is MIT, and the README asks you to see the License File, LICENSE.md, for more information. That is permissive enough that it will not be the reason you decline the package. The packaging is unusual in a way that tells you about the project. There is a Postcardware section, which says you are free to use the package but that if it makes it to your production environment the authors highly appreciate a postcard from your hometown mentioning which of their packages you are using. The address is Spatie, Kruikstraat 22, 2018 Antwerp, Belgium, and the postcards are published on their virtual postcard wall. There is also a Support us section asking you to buy one of their paid products, and an offer of resources invested in creating best in class open source packages. This is a company that funds open source from paid products, and the README is upfront about it rather than hiding the commercial angle. For an engineer evaluating the package, none of that is a technical concern. It does tell you the expected shape of the relationship: you depend on a package maintained by a business, which is a different risk profile from depending on an individual, and usually a better one. Security reporting has its own channel. The README asks that if you have found a bug regarding security you mail security@spatie.be instead of using the issue tracker. For a package that stores an append-only log of domain events, that channel matters more than it would for a utility package, because the stored events are the historical record your application trusts. ## Where laravel-event-sourcing is the wrong choice The failure modes here are architectural, not technical, and they are worth naming before you write the first aggregate. The first is a CRUD application with no need for history. If the current row state is the only thing anyone queries and nobody will ever ask why a value changed, event sourcing adds a write path, a projection pipeline and a storage cost for a log nobody reads. The README's own three questions are the test, and if you cannot answer at least one of them affirmatively, the package is solving a problem you do not have. The second is retrofitting a large existing codebase. This is not stated in the README, but the structure of the package implies it: aggregates are a root object model, and you cannot wrap an existing set of tables in one without changing how the code that touches them works. The third Larabank example shows aggregates and projectors from the start, not added later. The third is confusing projections with the source of truth. A projector is asynchronous or synchronous work that derives a read model from the event log. If your application's reads must be immediately consistent with a write that just happened, you need the synchronous projector mode and you need to understand the failure case where the write succeeds and the projection fails. The fourth is expecting concurrency handling. Nothing in the README describes optimistic locking, conflict detection or ordering guarantees for concurrent writes to the same aggregate. An aggregate that decides based on its own recorded history assumes it is the only writer for that aggregate at that moment. And the fifth is treating the package as a framework. It is an entry point. The Laravel integration, the Artisan commands and the stubs make the work pleasant, but the event model, the naming of your aggregates and the shape of your event classes are all decisions you make. ## An active release line with a versioned docs path The maintenance facts are straightforward. The repository is not archived, and the last push was on 2026-10-19, the same day as the 7.15.2 release. The recent release list shows 7.15.2 on 2026-10-19, 7.15.1 on 2026-08-10 and 7.15.0 on 2026-02-22. Those are patch releases on a stable 7.x line rather than a stream of major versions, which is the release pattern you want from a package that other people's domain models depend on. The version number of the package does not track the Laravel major version, which means an upgrade of either one does not force an upgrade of the other. The package is published on Packagist as spatie/laravel-event-sourcing, and the repository carries a GitHub Actions test workflow badge, so the test suite runs in CI. Two smaller details in the repository layout tell you about the maintainers' practices. The psalm.xml file at the root means the package is statically analysed, and the tests/ directory with phpunit.xml.dist means it has a test suite. Both are signs that the code is meant to be relied on rather than read once and copied. The documentation URL carries the version, which is how you should read this package in general: pick the documentation for the version you have installed, because an event sourcing API is exactly the kind of thing where a renamed method in a new major costs you an afternoon. ## Conclusion Adopt laravel-event-sourcing if your Laravel application has auditing requirements, needs to make decisions from history, or will need reporting over data you cannot predict today, because those are the three situations the package names as good candidates. Do not adopt it for a CRUD application where the current table state is the only truth you care about, and do not adopt it expecting the framework to solve concurrent writes for you. Before you commit, read the getting familiar with event sourcing section in the docs to see whether the aggregate, projector and reactor model matches how your team thinks, and look at the three Larabank example apps, since the traditional, projector, and projector-with-aggregates versions show the same banking app at three levels of adoption. ## FAQ ### What does spatie/laravel-event-sourcing do? It is a package for getting started with event sourcing in Laravel, helping you set up aggregates, projectors and reactors. The README describes it as the entry point for event sourcing in a Laravel application. ### When is event sourcing a good fit for a Laravel app? The README lists three situations: when the app needs to make decisions based on the past, when it has auditing requirements so the reason for the current state matters as much as the state, and when you foresee a reporting need but do not yet know which data to collect. ### Where are the installation instructions for laravel-event-sourcing? The README does not contain an install command. It points to the dedicated documentation site at spatie.be/docs/laravel-event-sourcing/v7/introduction for installation instructions and detailed usage. ### How is laravel-event-sourcing different from laravel-event-projector? The package supercedes laravel-event-projector and has the same API, so upgrading is easy according to the README. An upgrade guide is in the UPGRADING.md file in the repository root. ### Are there example applications for laravel-event-sourcing? Yes. The README lists three Larabank example apps in which you can create accounts and deposit or withdraw money: built traditionally without event sourcing, built with projectors, and built with aggregates and projectors. ### What licence is spatie/laravel-event-sourcing released under? The MIT License, with the details in the LICENSE.md file in the repository root. Security issues should be reported by mail to security@spatie.be rather than through the issue tracker. ## Sources - [License: MIT](https://github.com/spatie/laravel-event-sourcing/blob/main/LICENSE) - [Project website](https://docs.spatie.be/laravel-event-sourcing) - [README](https://github.com/spatie/laravel-event-sourcing/blob/main/README.md) - [Releases](https://github.com/spatie/laravel-event-sourcing/releases) - [spatie/laravel-event-sourcing on GitHub](https://github.com/spatie/laravel-event-sourcing) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/spatie-laravel-event-sourcing