Usage with Laravel-data?

[ovp87]

Does this package work well when paired with the laravel-data package?
What are the lessons learned by the people who have used both? Specifically i'm wondering how well it works to pass DTO's into events.

I haven't done a ton of testing yet, but already seeing some possible roadblocks while testing, like:

$aggregateFake->...->assertRecorded([
    new BuyableWasAddedToCart($buyable, 2),
]);

Failed asserting that two arrays are equal.
--- Expected
+++ Actual
@@ @@
         'buyable' => ..\BuyableData Object (
             '_additional' => []
-            '_dataContext' => Spatie\LaravelData\Support\Transformation\DataContext Object (...)
+            '_dataContext' => null

[sebastiandedeyne]

See #450 (comment) for our preferred way of using stored events with Laravel Data.

[ovp87]

Thanks for responding! 👍

I see, it never occured to me, to have each event become a DTO.

i'll need to do some more investigating, i assume that comment is referring to an older version of laravel-data, as i dont see a Datatrait any more.

[sebastiandedeyne]

It still exists but has been split across multiple traits: https://github.com/spatie/laravel-data/blob/16a842afddd1796d4e322347a4285960895814a9/src/Data.php#L26-L34

For events, I believe you'll need BaseData and TransformableData

[inmanturbo]

Example with current Laravel data:

Base event

use Illuminate\Contracts\Support\Responsable;
use Spatie\EventSourcing\StoredEvents\ShouldBeStored;
use Spatie\LaravelData\Concerns\AppendableData;
use Spatie\LaravelData\Concerns\BaseData;
use Spatie\LaravelData\Concerns\ContextableData;
use Spatie\LaravelData\Concerns\EmptyData;
use Spatie\LaravelData\Concerns\IncludeableData;
use Spatie\LaravelData\Concerns\ResponsableData;
use Spatie\LaravelData\Concerns\TransformableData;
use Spatie\LaravelData\Concerns\ValidateableData;
use Spatie\LaravelData\Concerns\WrappableData;
use Spatie\LaravelData\Contracts\AppendableData as AppendableDataContract;
use Spatie\LaravelData\Contracts\BaseData as BaseDataContract;
use Spatie\LaravelData\Contracts\EmptyData as EmptyDataContract;
use Spatie\LaravelData\Contracts\IncludeableData as IncludeableDataContract;
use Spatie\LaravelData\Contracts\ResponsableData as ResponsableDataContract;
use Spatie\LaravelData\Contracts\TransformableData as TransformableDataContract;
use Spatie\LaravelData\Contracts\ValidateableData as ValidateableDataContract;
use Spatie\LaravelData\Contracts\WrappableData as WrappableDataContract;

abstract class EventWithData extends ShouldBeStored implements AppendableDataContract, BaseDataContract, EmptyDataContract, IncludeableDataContract, Responsable, ResponsableDataContract, TransformableDataContract, ValidateableDataContract, WrappableDataContract
{
    use AppendableData;
    use BaseData;
    use ContextableData;
    use EmptyData;
    use IncludeableData;
    use ResponsableData;
    use TransformableData;
    use ValidateableData;
    use WrappableData;
}

Event

use Spatie\EventSourcing\Commands\AggregateUuid;

class PasswordChanged extends EventWithData
{
    public function __construct(
        #[AggregateUuid]
        public string $userUuid,
        public string $password,
    ) {}
}

Command

use Spatie\EventSourcing\Commands\HandledBy;

#[HandledBy(AuthAggregate::class)]
class ChangePassword extends PasswordChanged
{
    //
}

Auth aggregate:

public function changePassword(ChangePassword $command): void
{
    $this->recordThat(PasswordChanged::from($command->toArray()));
}

Usage

CommandBus::dispatch(new ChangePassword(
    userUuid: $user->uuid,
    password: Hash::make($input['password']),
));

[inmanturbo]

One gotcha to look out for: if you are doing this in a package make sure you register the LaravelData service provider inside your base test class.

[inmanturbo]

@ovp87 forgot to share the serializer for the above example:

use Spatie\EventSourcing\EventSerializers\JsonEventSerializer;
use Spatie\EventSourcing\StoredEvents\ShouldBeStored;

class DataEventSerializer extends JsonEventSerializer
{
    public function serialize(ShouldBeStored $event): string
    {
        if ($event instanceof EventWithData) {
            return $event->toJson();
        }

        return parent::serialize($event);
    }

    public function deserialize(string $eventClass, string $json, int $version, ?string $metadata = null): ShouldBeStored
    {
        if (is_subclass_of($eventClass, EventWithData::class)) {
            return $eventClass::from(json_decode($json, true));
        }

        return parent::deserialize($eventClass, $json, $version, $metadata);
    }
}

config:

// event-sourcing.php

return [
//...
    /*
     * This class is responsible for serializing events. By default an event will be serialized
     * and stored as json. You can customize the class name. A valid serializer
     * should implement Spatie\EventSourcing\EventSerializers\EventSerializer.
     */
    'event_serializer' => App\DataEventSerializer::class,
//...
];

[ovp87]

Cheers! saved me a bit of time 👍

[ovp87]

Perhaps a bit of necromancy here, reviving an old post, but i was thinking, is it even a good idea to pass dto's to events in this manner?

In my experience dto's have a tendency to change/evolve. Which would obviously become an issue on stored events, and essentially force you to version the dto's in addition to the events. (Or at the very least be VERY mindful about how you change them).

Unless im missing something, i guess its likely better to just pass primitives, with versioned events as needed..?

[inmanturbo]

I prefer to use a command (simple dto) that is constructed from primitives, then use that to hydrate the event, the other option is to simply pass the primitives themselves as arguments in an aggregate method, then use the primitives to hydrate the event. 🤷

[inmanturbo]

One thing to note: I would recommend passing the event object itself around the UI and controller actions, etc. Part of the advantage of having a command as a separate object (even though it extends the event class in the example I gave) is that you can make changes to the command if you need to, without changing the event, you just need to ensure the events are still getting constructed properly.

[sebastiandedeyne]

Perhaps a bit of necromancy here, reviving an old post, but i was thinking, is it even a good idea to pass dto's to events in this manner?

This is why we avoid having complex data objects as event properties. But there are cases where you do want Data objects as properties.

For example, we'd have a CreateEventData object which uses a Period to store start/end date:

class CreateEventData extends Data
{
    public function __construct(
        public string $name,
        public Period $period,
    ) {}
}

class Period extends Data
{
    public function __construct(
        public CarbonImmutable $starts_at,
        public CarbonImmutable $ends_at,
    ) {}
}

In our event sourced code, I would not like to reference CreateEventData because it's coupled to our UI/application affordances which may change over time.

However, I wouldn't mind using Period because it's a value object that uses Data.

In our AR (or an action), I'd map the data to the event which uses Laravel Data for easy (de)serialization.

class EventAggregateRoot extends AggregateRoot
{
    public function create(CreateEventData $data)
    {
        $this->recordThat(new EventCreated(
            name: $data->name,
            period: $data->period,
        ));
    }
}

class EventCreated extends DataShouldBeStored
{
    public function __construct(
        public string $name,
        public Period $period,
    ) {}
}