Hey people! I hope you’re doing great 💡 I don’t know if this topic was already raised (I am pr

Chemaclass

Hey people! I hope you’re doing great 💡

I don’t know if this topic was already raised (I am pretty sure it was already mention by someone), but I would like to put it on the table. It’s about Value Objects (VO). Let’s consider a real and useful example: The Sku. Wouldn’t be nice to have an Sku Value Object which can ensure the consistency of its value at the time when it’s being used or expected?

Currently we are using primitive data (int, float, string), or other Transfer Objects, in all Transfers, but wouldn’t be nice to use VO for some values instead of the raw type? I think the Sku is a nice example:

final class Sku 
{
    private string $sku;

    public static function fromString(string $sku): self
    {
        Assert::notEmpty($sku); // or whatever assertion logic that you want to have

        return new self($sku);
    }

    public function asString(): string
    {
        return $this->sku;
    }
}

I was thinking, as something that could be customised by the end client, similar as we can define the Transfers (and generate them out of the box based on some custom xml configuration). Usually a Sku must be in a certain length and never being empty, so such rules/assertions could be customised 🤔 Of course, this Sku is just an opportunity example of a simple VO that could be applied to some other (more complex) VOs.

The clear benefits of this proposal/idea is that you can expect certain types in your functions that depend on specific VO and not simply raw types. I think this would be an awesome step to improve the user experience with Transfers Objects. What do you think?

Ahmed Sabaa

I think it’s a great idea, although I am not sure about the immutability aspect of it while working on Spryker projects. Part of the coolness (and headache) of transfer objects is that they are actually mutable and allow side effects even (nightmare or feature?). It allows for a lot of flexibility especially when developing a lot of things in core. Now should we have VOs allowed in Transfer object definition and let projects run away with it? Absolutely! It might be a great way to ensure some sort of sanity on project level. But those VOs will probably not appear on core level. Just FYI, we currently have such support for VOs of Spryker’s internal implementation of https://github.com/spryker/decimal-object. I am not sure how extendible it is to enable other kinds of VOs though

UKHD8KTMF

Also as transfer objects are serialized from/to JSON when we can ZED from client we need to make sure that we do not break this.

UKHD8KTMF

You can also make your own transfer objects by extending AbstractTransfer or existing transfer.

Ahmed Sabaa

If you’d like to introduce such things in your project, maybe take a look at \Spryker\Zed\Transfer\Business\Model\Generator\ClassDefinition::SUPPORTED_VALUE_OBJECTS . Just keep in mind that overwriting Transfer module on project level just for this particular feature might stop you from gaining access to future Spryker bugfixes/features in the Transfer module!