Non-traditional meaning of "value object" used

[matthiasnoback]

Hey everyone, I noticed this library being announced on Twitter. To be very honest, I think it's weird that this library and its documentation use the term "value object". How this term is used in the software development world and in the DDD community in particular corresponds in almost no way to how this library uses it. Could you maybe cast some light on this from your perspective?

[brendt]

Naming is hard... It's "an object concerned with passing data", in other words: values.

That's where the name came from, but I understand the confusion. We briefly considered calling it plain "struct" but that seemed too low level (I personally compared it to structs in Rust).

I also considered the name "data transfer object", but I was afraid people would say that it didn't adhere to the DDD definition. I was trying to avoid the exact problem you're (rightfully) addressing now 😅

You're maybe aware that we're not following strict DDD rules in our projects. Sure we use some principles from the DDD community, but definitely not all. This explains why I didn't immediately saw any issue with the name "value object".

Anyways, I don't mind changing the name, but I cannot think of any good alternative that's not reserved yet... Any ideas?

[nyamsprod]

Maybe you should call this package a Data Wrapper Object since what your are doing is basically encapsulating the original data contained in the array using an object oriented API ? Better Yet a ArrayWrapper object.

[skyrpex]

I actually find ValueObjecta good name for the class and the repository. It's an object that contains valid values.

[nyamsprod]

Well that's not the definition of a Value Object.

In computer science, a value object is a small object that represents a simple entity whose equality is not based on identity: i.e. two value objects are equal when they have the same value, not necessarily being the same object. Wikipedia

For instance a DateTime is a value object and a DateTimeImmutable is an immutable value object.

This package, on the other hand, marshaled, optionally validated and finally converts data contains in a array in a convenient object structure. As you can see the usage is radically different and the naming is misleading.

[skyrpex]

Thanks for the Wikipedia reference, @nyamsprod. It may only occur to me, but I see that the description in the Wiki correctly applies to what this library offers:

• Two value objects are equal when they have the same value (PHP also requires that they are the same class).

For example, why can't this be considered a value object?

class IndexUsersOptions extends ValueObject
{
    /** @var int */
    public $page;
    /** @var int */
    public $perPage;
    /** @var int|null; */
    public $age;
}

[ghost]

DataObject? Avoids collision with both DataTransferObject and ValueObject.

[nyamsprod]

@skyrpex

PHP also requires that they are the same class

There is no such requirement in PHP

[skyrpex]

@skyrpex

PHP also requires that they are the same class

There is no such requirement in PHP

In order to the equality return true, yes. See http://sandbox.onlinephpfunctions.com/code/5c09aeb96292e677cc8f51f45b896e80e3b48238.

<?php

class ValueObject
{
}

class ExampleA extends ValueObject
{
    public $int;
    
    public $string;
}

class ExampleB extends ValueObject
{
    public $int;
    
    public $string;
}

// ExampleA and ExampleA are equal
$a = new ExampleA;
$a->int = 123;
$a->string = "abc";

$b = new ExampleA;
$b->int = 123;
$b->string = "abc";

var_dump($a == $b); // prints true

// ExampleA and ExampleB are different
$a = new ExampleA;
$a->int = 123;
$a->string = "abc";

$b = new ExampleB;
$b->int = 123;
$b->string = "abc";

var_dump($a == $b); // prints false

[matthiasnoback]

Actually, "DataTransferObject" wouldn't be a crazy idea after all. In fact, I created some package myself some time ago to implement the immutability aspect for DTOs that you're after with this library too (https://github.com/matthiasnoback/convenient-immutability). But you're also implementing typed properties, which is cool. What's important to me is that a DTO is an object you can decide to "populate" in part (whereas a Value Object can never exist in an incomplete or inconsistent state). Comparing Value Objects is indeed about equality (I didn't know about PHP's ability to ignore the class and only look at the values by the way!). But it's more about the correct representation of a domain concept. I don't think you could ever write a library that would help with that. All Value Objects are custom-made. For DTOs though, a library like this can be useful. It's just for passing around data (from JSON string or POST request data to application service, or to a template).

"DataObject" could be an option too, but you'd be introducing a technical term that isn't available yet (afaik). Plus it's way too generic in my opinion. You could also describe what this library offers, e.g. "ImmutableTypeSafeDTOs". In my opinion there's no correct DDD definition of a "DTO", but there is one for a "Value object", which leads me to conclude that it's better to let go of "Value object", and use "DTO" instead.

A little background: I'm offering training on topics like DDD and it's already had to for people to grasp the idea behind a value object and implement it right. So I don't think it should be any more confusing by mixing up terminology.

[brendt]

So I don't think it should be any more confusing by mixing up terminology.

I agree Matthias. We discussed the name of this package at length last Friday, and decided we're going to change the name.

We settled on DataObject, because I was afraid of "claiming" the name DataTransferObject. However, if you think of it as a valid option to use DTO, I think we should go with it.

I'll leave this issue open for a few more hours, to see if there's any more input. Without any good arguments against DataTransferObject, it'll be the new name of this package later today or tomorrow.

[matthiasnoback]

Cool! Yes, I consider "DTO" a valid option here. Keep up the good work!

[matthiasnoback]

Also, thanks for a fruitful discussion and thanks everyone for their input.

[nyamsprod]

@skyrpex value object equality is different from PHP object equality.
@matthiasnoback @brendt I agree that Data Transfer Object looks better to me too 👍

[driesvints]

DataTransferObject is a good name. I now actually realize that I've been doing the same thing in a previous project at one point and we always called those object DTO's.

[brendt]

Took a bit longer than expected, but the package is now called data-transfer-object.

[matthiasnoback]

Cool!