Add Message header interface for more decoupling and type safety

[DanielBadura]

No description provided.

[DavidBadura]

That's kind of how I thought it too 👍

[github-actions]

Hello 👋

here is the most recent benchmark result:

SnapshotsBench
==============

+----------------------------------------+--------------------+--------------------+-----------------+------------+
|                                        | time (kde mode)                         | memory                       |
+----------------------------------------+--------------------+--------------------+-----------------+------------+
| subject                                | Tag: <current>     | Tag: base          | Tag: <current>  | Tag: base  |
+----------------------------------------+--------------------+--------------------+-----------------+------------+
| benchLoad10000EventsMissingSnapshot () | 159.050ms (±0.00%) | 167.243ms (±0.00%) | 38.681mb        | 38.681mb   |
| benchLoad10000Events ()                | 530.000μs (±0.00%) | 521.700μs (±0.00%) | 38.681mb        | 38.681mb   |
+----------------------------------------+--------------------+--------------------+-----------------+------------+

SimpleSetupBench
================

+----------------------------------------+--------------------+--------------------+-----------------+------------+
|                                        | time (kde mode)                         | memory                       |
+----------------------------------------+--------------------+--------------------+-----------------+------------+
| subject                                | Tag: <current>     | Tag: base          | Tag: <current>  | Tag: base  |
+----------------------------------------+--------------------+--------------------+-----------------+------------+
| benchLoad10000Events ()                | 158.057ms (±0.00%) | 171.136ms (±0.00%) | 38.684mb        | 38.663mb   |
| benchSave1Event ()                     | 871.300μs (±0.00%) | 901.100μs (±0.00%) | 38.684mb        | 38.663mb   |
| benchSave10000Events ()                | 473.695ms (±0.00%) | 485.517ms (±0.00%) | 38.951mb        | 38.940mb   |
| benchSave10000Aggregates ()            | 8.605s (±0.00%)    | 8.987s (±0.00%)    | 38.684mb        | 38.663mb   |
| benchSave10000AggregatesTransaction () | 7.381s (±0.00%)    | 7.398s (±0.00%)    | 38.684mb        | 38.663mb   |
+----------------------------------------+--------------------+--------------------+-----------------+------------+

SplitStreamBench
================

+-------------------------+--------------------+--------------------+-----------------+------------+
|                         | time (kde mode)                         | memory                       |
+-------------------------+--------------------+--------------------+-----------------+------------+
| subject                 | Tag: <current>     | Tag: base          | Tag: <current>  | Tag: base  |
+-------------------------+--------------------+--------------------+-----------------+------------+
| benchLoad10000Events () | 5.309ms (±0.00%)   | 5.597ms (±0.00%)   | 42.549mb        | 41.963mb   |
| benchSave10000Events () | 624.281ms (±0.00%) | 631.580ms (±0.00%) | 42.826mb        | 42.250mb   |
+-------------------------+--------------------+--------------------+-----------------+------------+

ProjectionistBench
==================

+---------------------------+-----------------+-----------------+-----------------+------------+
|                           | time (kde mode)                   | memory                       |
+---------------------------+-----------------+-----------------+-----------------+------------+
| subject                   | Tag: <current>  | Tag: base       | Tag: <current>  | Tag: base  |
+---------------------------+-----------------+-----------------+-----------------+------------+
| benchHandle10000Events () | 3.294s (±0.00%) | 3.341s (±0.00%) | 39.079mb        | 39.102mb   |
+---------------------------+-----------------+-----------------+-----------------+------------+

This comment gets update everytime a new commit comes in!

[DanielBadura]

Do we even need the SerializedHeader dto?

[DavidBadura]

Nice work 👍 I still have a few wishes :D

[DavidBadura]

We should add the default headers internally, so the developer no need to know, that he need a specific path. And we should do this without a path: we should add our headers directly. auto-discovery should only used in user space.

[DanielBadura]

Hm, I'm not sure about that. Due to that it's more masked for the user that this is happening and if he implements his own version of the HeadersSerializer he needs to know this internal logic in our DefaultHeadersSerializer.

But if we we do this then i think we should keep it as auto discover due two reasons:

1. We cannot forget to add headers then there
2. No need for extra logic

[DavidBadura]

1. I don't think it's a relevant point that you forget it, since we'll hopefully cover it with tests so that everything fits.

2. We can push the logic further down to MessageHeaderRegistry.

class MessageHeaderRegistry
{
    // ...
    
    /** @param array<string, class-string<Header>> $headerNameToClassMap */
    public static function withInternalHeaders(array $headerNameToClassMap): self
    {
        $internalHeaders = [
            'aggregate' => AggregateHeader::class,
            // ...
        ];
    
        return new self($headerNameToClassMap + $internalHeaders);
    }
}

This means it cannot be forgotten in the serializer.

To the point that no extra logic is necessary: It's an array merge, there isn't that much extra logic. On the other hand, we have an IO search in our code, which is not necessary because we know exactly where the classes are.

[DanielBadura]

Then we are duplicating the naming code 🤔
So i think, if we move it, it should land in AttributeMessageHeaderRegistryFactory but still feels weird.

        $classes = (new ClassFinder())->findClassNames($paths);
        $classes = array_merge([AggregateHeader::class, ...], $classes);

[DavidBadura]

Then we are duplicating the naming code 🤔

I do not understand that.

For me, MessageHeaderRegistry would be the more correct place. I wouldn't put it any further down.

[DavidBadura]

If you mean the attributes. I would remove these from the internal headers because the attributes are only used for configuration. And since we define the internal headers differently, they have no meaning there. The attribute is for user space.