diff --git a/docs/advanced-usage/replaying-events.md b/docs/advanced-usage/replaying-events.md index 377bc991..68490193 100644 --- a/docs/advanced-usage/replaying-events.md +++ b/docs/advanced-usage/replaying-events.md @@ -3,11 +3,11 @@ title: Replaying events weight: 2 --- -All [events](/laravel-event-sourcing/v1/advanced-usage/preparing-events/) that implement `Spatie\EventSourcing\ShouldBeStored` will be [serialized](/laravel-event-sourcing/v1/advanced-usage/using-your-own-event-serializer) and stored in the `stored_events` table. After your app has been doing its work for a while the `stored_events` table will probably contain some events. +All [events](/laravel-event-sourcing/v3/advanced-usage/preparing-events/) that implement `Spatie\EventSourcing\ShouldBeStored` will be [serialized](/laravel-event-sourcing/v3/advanced-usage/using-your-own-event-serializer) and stored in the `stored_events` table. After your app has been doing its work for a while the `stored_events` table will probably contain some events. - When creating a new [projector](/laravel-event-sourcing/v1/using-projectors/writing-your-first-projector/) or [reactor](/laravel-event-sourcing/v1/using-reactors/writing-your-first-reactor/) you'll want to feed all stored events to that new projector or reactor. We call this process replaying events. + When creating a new [projector](/laravel-event-sourcing/v3/using-projectors/writing-your-first-projector/) you'll want to feed all stored events to that new projector. We call this process replaying events. - Events can be replayed to [all projectors that were added to the projectionist](/laravel-event-sourcing/v1/using-projectors/creating-and-configuring-projectors/) with this artisan command: + Events can be replayed to [all projectors that were added to the projectionist](/laravel-event-sourcing/v3/using-projectors/creating-and-configuring-projectors/) with this artisan command: ```bash php artisan event-sourcing:replay @@ -29,7 +29,7 @@ If your projector has a `resetState` method it will get called before replaying If you want to replay events starting from a certain event you can use the `--from` option when executing `event-sourcing:replay`. If you use this option the `resetState` on projectors will not get called. This package does not track which events have already been processed by which projectors. Be sure not to replay events to projectors that already have handled them. -If you are [using your own event storage model](/laravel-event-sourcing/v1/advanced-usage/using-your-own-event-storage-model/) then you will need to use the `--stored-event-model` option when executing `event-sourcing:replay` to specify the model storing the events you want to replay. +If you are [using your own event storage model](/laravel-event-sourcing/v3/advanced-usage/using-your-own-event-storage-model/) then you will need to use the `--stored-event-model` option when executing `event-sourcing:replay` to specify the model storing the events you want to replay. ```bash php artisan event-sourcing:replay --stored-event-model=App\\Models\\AccountStoredEvent diff --git a/docs/advanced-usage/storing-metadata.md b/docs/advanced-usage/storing-metadata.md index 9403c714..efe7f509 100644 --- a/docs/advanced-usage/storing-metadata.md +++ b/docs/advanced-usage/storing-metadata.md @@ -9,7 +9,7 @@ You can add metadata, such as the `id` of the logged in user, to a stored event. If you need to store metadata on all events you can leverage Laravel's native models events when using the `EloquentStoredEventRepository`. -You must configure the package to [use your own eloquent event storage model](/laravel-event-sourcing/v1/advanced-usage/using-your-own-event-storage-model) that extends the `EloquentStoredEvent` model. On that model you can hook into the model lifecycle hooks. +You must configure the package to [use your own eloquent event storage model](/laravel-event-sourcing/v3/advanced-usage/using-your-own-event-storage-model) that extends the `EloquentStoredEvent` model. On that model you can hook into the model lifecycle hooks. ```php use Spatie\EventSourcing\Models\EloquentStoredEvent; diff --git a/docs/getting-familiar-with-event-sourcing/introduction.md b/docs/getting-familiar-with-event-sourcing/introduction.md index b3a02987..56a062bb 100644 --- a/docs/getting-familiar-with-event-sourcing/introduction.md +++ b/docs/getting-familiar-with-event-sourcing/introduction.md @@ -9,7 +9,7 @@ Event sourcing tries to solve this problem by storing all events that happen in Here's a concrete example to make it more clear. Imagine you're a bank. Your clients have accounts. Storing the balance of the accounts wouldn't be enough; all the transactions should be remembered too. With event sourcing, the balance isn't a standalone database field, but a value calculated from the stored transactions. -After taking a look at [an example of traditional application](/laravel-event-sourcing/v1/getting-familiar-with-event-sourcing/the-traditional-application), we're going to discuss the two concepts that make up this package: [projectors](/laravel-event-sourcing/v1/getting-familiar-with-event-sourcing/using-projectors-to-transform-events) and [aggregates](/laravel-event-sourcing/v1/getting-familiar-with-event-sourcing/using-aggregates-to-make-decisions-based-on-the-past). +After taking a look at [an example of traditional application](/laravel-event-sourcing/v3/getting-familiar-with-event-sourcing/the-traditional-application), we're going to discuss the two concepts that make up this package: [projectors](/laravel-event-sourcing/v3/getting-familiar-with-event-sourcing/using-projectors-to-transform-events) and [aggregates](/laravel-event-sourcing/v3/getting-familiar-with-event-sourcing/using-aggregates-to-make-decisions-based-on-the-past). If you want to skip to reading code immediately, here are the Larabank example apps used in this section. In all of them, you can create accounts and deposit or withdraw money. diff --git a/docs/getting-familiar-with-event-sourcing/using-aggregates-to-make-decisions-based-on-the-past.md b/docs/getting-familiar-with-event-sourcing/using-aggregates-to-make-decisions-based-on-the-past.md index e80f6a32..91b80106 100644 --- a/docs/getting-familiar-with-event-sourcing/using-aggregates-to-make-decisions-based-on-the-past.md +++ b/docs/getting-familiar-with-event-sourcing/using-aggregates-to-make-decisions-based-on-the-past.md @@ -53,4 +53,4 @@ Whenever we retrieve an aggregate, all of the previously stored events will be f In summary, aggregates are used to make decisions based on past events. -If you want to know how to create and use aggregates, head over to [the `using-aggregates` section](/laravel-event-sourcing/v1/using-aggregates/writing-your-first-aggregate). +If you want to know how to create and use aggregates, head over to [the `using-aggregates` section](/laravel-event-sourcing/v3/using-aggregates/writing-your-first-aggregate). diff --git a/docs/getting-familiar-with-event-sourcing/using-projectors-to-transform-events.md b/docs/getting-familiar-with-event-sourcing/using-projectors-to-transform-events.md index 356c1f31..140735be 100644 --- a/docs/getting-familiar-with-event-sourcing/using-projectors-to-transform-events.md +++ b/docs/getting-familiar-with-event-sourcing/using-projectors-to-transform-events.md @@ -3,7 +3,7 @@ title: Using projectors to transform events weight: 3 --- -Let's build a bit further on the [Larabank example](https://github.com/spatie/larabank-traditional) mentioned in [the previous section](/laravel-event-sourcing/v1/getting-familiar-with-event-sourcing/the-traditional-application). The main drawback highlighted that example is the fact that when updating a value, we lose the old value. Let's solve that problem. +Let's build a bit further on the [Larabank example](https://github.com/spatie/larabank-traditional) mentioned in [the previous section](/laravel-event-sourcing/v3/getting-familiar-with-event-sourcing/the-traditional-application). The main drawback highlighted that example is the fact that when updating a value, we lose the old value. Let's solve that problem. Instead of directly updating the value in the database, we could write every change we want to make as an event in our database. @@ -37,4 +37,4 @@ This package can help you store native Laravel events in a `stored_events` table Here's our example app [Larabank rebuild with projectors](https://github.com/spatie/larabank-projectors). In [the `AccountsController`](https://github.com/spatie/larabank-projectors/blob/677777c0cb7fd2584b54073ac82c91e25fd07d2b/app/Http/Controllers/AccountsController.php#L20-L36) we're not going to directly modify the database anymore. Instead, the controller will call methods which will in [their turn fire off events](https://github.com/spatie/larabank-projectors/blob/677777c0cb7fd2584b54073ac82c91e25fd07d2b/app/Account.php#L15-L41). Our package will listen for those events (which implement the empty `ShouldBeStored` interface) and store them in the `stored_events` table. Those events will also get passed to [all registered projectors](https://github.com/spatie/larabank-projectors/blob/677777c0cb7fd2584b54073ac82c91e25fd07d2b/config/event-sourcing.php#L18-L20). The [`AccountsProjector`](https://github.com/spatie/larabank-projectors/blob/677777c0cb7fd2584b54073ac82c91e25fd07d2b/app/Projectors/AccountsProjector.php) will build the `Accounts` table using [a couple of events it listens for](https://github.com/spatie/larabank-projectors/blob/677777c0cb7fd2584b54073ac82c91e25fd07d2b/app/Projectors/AccountsProjector.php#L17-L20). -If you want to know more about projectors and how to use them, head over to [the `using-projectors` section](/laravel-event-sourcing/v1/using-projectors/writing-your-first-projector). +If you want to know more about projectors and how to use them, head over to [the `using-projectors` section](/laravel-event-sourcing/v3/using-projectors/writing-your-first-projector). diff --git a/docs/installation-setup.md b/docs/installation-setup.md index 5e8ef70e..6de15047 100644 --- a/docs/installation-setup.md +++ b/docs/installation-setup.md @@ -104,7 +104,7 @@ return [ /* * In production, you likely don't want the package to auto discover the event handlers * on every request. The package can cache all registered event handlers. - * More info: https://docs.spatie.be/laravel-event-sourcing/v1/advanced-usage/discovering-projectors-and-reactors + * More info: https://docs.spatie.be/laravel-event-sourcing/v3/advanced-usage/discovering-projectors-and-reactors * * Here you can specify where the cache should be stored. */ @@ -112,7 +112,7 @@ return [ ]; ``` -The package will scan all classes of your project to [automatically discover projectors and reactors](/laravel-event-sourcing/v1/advanced-usage/discovering-projectors-and-reactors#discovering-projectors-and-reactors). In a production environment you probably should [cache auto discovered projectors and reactors](/laravel-event-sourcing/v1/advanced-usage/discovering-projectors-and-reactors#caching-discovered-projectors-and-reactors). +The package will scan all classes of your project to [automatically discover projectors and reactors](/laravel-event-sourcing/v3/advanced-usage/discovering-projectors-and-reactors#discovering-projectors-and-reactors). In a production environment you probably should [cache auto discovered projectors and reactors](/laravel-event-sourcing/v3/advanced-usage/discovering-projectors-and-reactors#caching-discovered-projectors-and-reactors). It's recommended that you set up a queue. Specify the connection name in the `queue` key of the `event-sourcing` config file. This queue will be used to guarantee that the events will be processed by all projectors in the right order. You should make sure that the queue will process only one job at a time. In a local environment, where events have a very low chance of getting fired concurrently, it's probably ok to just use the `sync` driver. diff --git a/docs/introduction.md b/docs/introduction.md index da72358f..bf9cfb0c 100644 --- a/docs/introduction.md +++ b/docs/introduction.md @@ -5,7 +5,7 @@ weight: 1 This package aims to be the entry point to get started with event sourcing in Laravel. It can help you setting up aggregates, projectors and reactors. -If you've never worked with event sourcing, or are uncertain about what projectors, reactors and aggregates are, head over to [the getting familiar with event sourcing section](/laravel-event-sourcing/v1/getting-familiar-with-event-sourcing/introduction). +If you've never worked with event sourcing, or are uncertain about what projectors, reactors and aggregates are, head over to [the getting familiar with event sourcing section](/laravel-event-sourcing/v3/getting-familiar-with-event-sourcing/introduction). Are you visual learner? Then start by watching this video. It explains event sourcing in general and how you can use projectors, reactors and aggregates. diff --git a/docs/using-aggregates/writing-your-first-aggregate.md b/docs/using-aggregates/writing-your-first-aggregate.md index 671c4904..62f982ab 100644 --- a/docs/using-aggregates/writing-your-first-aggregate.md +++ b/docs/using-aggregates/writing-your-first-aggregate.md @@ -3,7 +3,7 @@ title: Writing your first aggregate weight: 1 --- -An aggregate is a class that decides to record events based on past events. To know more about their general purpose and the idea behind them, read this section on [using aggregates to make decisions-based-on-the-past](/laravel-event-sourcing/v1/getting-familiar-with-event-sourcing/using-aggregates-to-make-decisions-based-on-the-past). +An aggregate is a class that decides to record events based on past events. To know more about their general purpose and the idea behind them, read this section on [using aggregates to make decisions-based-on-the-past](/laravel-event-sourcing/v3/getting-familiar-with-event-sourcing/using-aggregates-to-make-decisions-based-on-the-past). ## Creating an aggregate diff --git a/docs/using-projectors/creating-and-configuring-projectors.md b/docs/using-projectors/creating-and-configuring-projectors.md index d674b37e..e427980a 100644 --- a/docs/using-projectors/creating-and-configuring-projectors.md +++ b/docs/using-projectors/creating-and-configuring-projectors.md @@ -69,7 +69,7 @@ Just by adding a typehint of the event you want to handle makes our package call ## Getting the uuid of an event -In most cases you want to have access to the event that was fired. When [using aggregates](/laravel-event-sourcing/v1/using-aggregates/writing-your-first-aggregate) your events probably won't contain the uuid associated with that event. To get to the uuid of an event simply add a parameter called `$aggregateUuid` that typehinted as a string. +In most cases you want to have access to the event that was fired. When [using aggregates](/laravel-event-sourcing/v3/using-aggregates/writing-your-first-aggregate) your events probably won't contain the uuid associated with that event. To get to the uuid of an event simply add a parameter called `$aggregateUuid` that typehinted as a string. ```php // ... @@ -84,7 +84,7 @@ public function onMoneyAdded(MoneyAdded $event, string $aggregateUuid) } ``` -The order of the parameters giving to an event handling method like `onMoneyAdded`. We'll simply pass the uuid to any arguments named `$aggregateUuid`. +The order of the parameters giving to an event handling method like `onMoneyAdded` does not matter. We'll simply pass the uuid to any arguments named `$aggregateUuid`. ## Manually registering event handling methods diff --git a/docs/using-projectors/thinking-in-events.md b/docs/using-projectors/thinking-in-events.md index 5054339c..1c9e7943 100644 --- a/docs/using-projectors/thinking-in-events.md +++ b/docs/using-projectors/thinking-in-events.md @@ -3,9 +3,9 @@ title: Thinking in events weight: 5 --- -In this example we're going to try to send a mail whenever an account is broke (balance below zero). You can do this with projectors and reactors alone, but aggregates might be a better fit for this. Aggregates make it easy to make decisions based on past events. Check out the section on [how to use aggregates](/laravel-event-sourcing/v1/introduction) to learn more about them, or keep reading on this page if you don't want to use aggregates. +In this example we're going to try to send a mail whenever an account is broke (balance below zero). You can do this with projectors and reactors alone, but aggregates might be a better fit for this. Aggregates make it easy to make decisions based on past events. Check out the section on [how to use aggregates](/laravel-event-sourcing/v3/introduction) to learn more about them, or keep reading on this page if you don't want to use aggregates. -Let's build upon the examples shown in the [writing your first projector](/laravel-event-sourcing/v1/using-projectors/writing-your-first-projector) and [handling side effects with reactors](/laravel-event-sourcing/v1/using-reactors/writing-your-first-reactor)' sections. +Let's build upon the examples shown in the [writing your first projector](/laravel-event-sourcing/v3/using-projectors/writing-your-first-projector) and [handling side effects with reactors](/laravel-event-sourcing/v3/using-reactors/writing-your-first-reactor)' sections. Imagine you are tasked with sending a mail to an account holder whenever he or she is broke. You might think, that's easy, let's just check in a new reactor if the account balance is less than zero. diff --git a/docs/using-reactors/writing-your-first-reactor.md b/docs/using-reactors/writing-your-first-reactor.md index 01721813..c3ebe0ab 100644 --- a/docs/using-reactors/writing-your-first-reactor.md +++ b/docs/using-reactors/writing-your-first-reactor.md @@ -5,7 +5,7 @@ weight: 1 ## What is a reactor -Now that you've [written your first projector](/laravel-event-sourcing/v1/using-projectors/writing-your-first-projector), let's learn how to handle side effects. With side effects we mean things like sending a mail, sending a notification, ... You only want to perform these actions when the original event happens. You don't want to do this work when replaying events. +Now that you've [written your first projector](/laravel-event-sourcing/v3/using-projectors/writing-your-first-projector), let's learn how to handle side effects. With side effects we mean things like sending a mail, sending a notification, ... You only want to perform these actions when the original event happens. You don't want to do this work when replaying events. A reactor is a class, that much like a projector, listens for incoming events. Unlike projectors however, reactors will not get called when events are replayed. Reactors only will get called when the original event fires.