Events Groupping

[YOzaz]

Currently all events go to stored_events table, and all models, projectors, aggregators are very coupled together.
This is fine for simple projects, but in reality - when event sourcing comes into play - there may be a need for some advanced usages like:

• Decoupling and/or grouping related events into separate data storages. E.g. declare specific data target (table?) where they should be stored to.
• An abstraction layer to create snapshots of aggregate roots for caching purposes - for usage of engines like ElasticSearch.
• In general, grouping events into services or components by following DDD principles.

I know this may be achieved using patterns like microservices, but the package itself now is pretty much immutable - unless you want to get your hands dirty with heavy custom repository implementations. Unless I'm missing something.

[avosalmon]

I have the same concern. My application will fire hundreds of millions of events and it might not be scalable to store all events in a single table.
It would be great if we could store events in different tables depending on the domain of the event.
Let's say, we have an e-commerce application. Events that are related to the product domain will be stored in the product_events table and order-related events will be stored in the order_events.

[sebastiandedeyne]

I believe this wouldn't be too hard to achieve with a custom repository.

You could check the event namespace (or any other property) to determine the domain when persisting, and persist each in a separate table.

[avosalmon]

I think it works. I will explore the custom repository. Thanks!

[YOzaz]

Just to follow up, general table separation was pretty much described here:
https://laravel-news.com/event-sourcing-in-laravel
because "This is explained in the package documentation, but I will walk you through it myself as it wasn't the clearest in the docs." :)
My topic was about more advanced techniques like even using a different data storage driver per group.

[avosalmon]

This is what I did.

1. Create a custom EloquentStoredEvent

Create a custom EloquentStoredEvent per domain. It only overwrites the table name for the event store.

<?php

declare(strict_types=1);

namespace Domain\Analytics\Models;

use Spatie\EventSourcing\StoredEvents\Models\EloquentStoredEvent;

class AnalyticsStoredEvent extends EloquentStoredEvent
{
    protected $table = 'analytics_stored_events';
}

2. Create a custom EloquentStoredEventRepository

The custom repository will get the proper EloquentStoredEvent instance based on the event's domain.

<?php

declare(strict_types=1);

namespace App\Repositories;

use Domain\Analytics\Domain\Models\AnalyticsStoredEvent;
use Domain\Verification\Domain\Models\VerificationStoredEvent;
use Carbon\Carbon;
use Spatie\EventSourcing\Enums\MetaData;
use Spatie\EventSourcing\EventSerializers\EventSerializer;
use Spatie\EventSourcing\StoredEvents\Models\EloquentStoredEvent;
use Spatie\EventSourcing\StoredEvents\Repositories\EloquentStoredEventRepository as BaseRepository;
use Spatie\EventSourcing\StoredEvents\ShouldBeStored;
use Spatie\EventSourcing\StoredEvents\StoredEvent;
use UnhandledMatchError;

class EloquentStoredEventRepository extends BaseRepository
{
    /**
     * Persist the event to the domain-specific event store based on the event's domain.
     */
    public function persist(ShouldBeStored $event, string $uuid = null): StoredEvent
    {
        $eloquentStoredEvent = $this->getStoredEventModel($event);

        $eloquentStoredEvent->setOriginalEvent($event);

        $createdAt = Carbon::now();

        $eloquentStoredEvent->setRawAttributes([
            'event_properties' => app(EventSerializer::class)->serialize(clone $event),
            'aggregate_uuid' => $uuid,
            'aggregate_version' => $event->aggregateRootVersion(),
            'event_version' => $event->eventVersion(),
            'event_class' => $this->getEventClass(get_class($event)),
            'meta_data' => json_encode($event->metaData() + [
                MetaData::CREATED_AT => $createdAt->toDateTimeString(),
            ]),
            'created_at' => $createdAt,
        ]);

        $eloquentStoredEvent->save();

        $eloquentStoredEvent->meta_data->set(MetaData::STORED_EVENT_ID, $eloquentStoredEvent->id);

        $eloquentStoredEvent->save();

        $eloquentStoredEvent->event->setStoredEventId($eloquentStoredEvent->id);

        return $eloquentStoredEvent->toStoredEvent();
    }

    private function getStoredEventModel(ShouldBeStored $event): EloquentStoredEvent
    {
        // Retrieve "Verification" from "Domain\Verification\Events\DocumentWasVerified"
        $domain = explode('\\', $event::class)[1];

        return match ($domain) {
            'Analytics' => new AnalyticsStoredEvent(),
            'Verification' => new VerificationStoredEvent(),
            default => throw new UnhandledMatchError($domain),
        };
    }

    private function getEventClass(string $class): string
    {
        $map = config('event-sourcing.event_class_map', []);

        if (! empty($map) && in_array($class, $map)) {
            return array_search($class, $map, true);
        }

        return $class;
    }
}

3. Register the custom repository in the config

'stored_event_repository' => App\Repositories\EloquentStoredEventRepository::class,

For Aggregate

The above approach only works if you directly dispatch an event without Aggregate.
If you wish to use Aggregate, create a custom repository per domain and overwrite the getStoredEventRepository() method in the Aggregate class.

<?php

declare(strict_types=1);

namespace Domain\Analytics\Repositories;

use Domain\Analytics\Models\AnalyticsStoredEvent;
use Spatie\EventSourcing\StoredEvents\Repositories\EloquentStoredEventRepository as BaseRepository;

class AnalyticsStoredEventRepository extends BaseRepository
{
    public function __construct(protected string $storedEventModel = AnalyticsStoredEvent::class)
    {
    }
}

<?php

declare(strict_types=1);

namespace Domain\Analytics\Aggregates;

use Domain\Analytics\Repositories\AnalyticsStoredEventRepository;
use Spatie\EventSourcing\AggregateRoots\AggregateRoot;
use Spatie\EventSourcing\StoredEvents\Repositories\StoredEventRepository;

final class AnalyticsAggregateRoot extends AggregateRoot
{
    protected function getStoredEventRepository(): StoredEventRepository
    {
        return app()->make(AnalyticsStoredEventRepository::class);
    }
}

[avosalmon]

There is a caveat when replaying events.
php artisan event-sourcing:replay command does not support a custom repository or custom model.

If you are 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.

The package's doc says that we can pass --stored-event-model option to the replay command to specify the model storing the events, however, it does not work. This option is not used in the command.

As a workaround, we need to temporarily change the config event-sourcing.stored_event_model to a custom model when we replay events.