Non-traditional meaning of "value object" used #17
Comments
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? |
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 |
I actually find |
Well that's not the definition of a Value Object.
For instance a 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. |
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:
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;
} |
DataObject? Avoids collision with both DataTransferObject and ValueObject. |
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 |
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. |
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 I'll leave this issue open for a few more hours, to see if there's any more input. Without any good arguments against |
Cool! Yes, I consider "DTO" a valid option here. Keep up the good work! |
Also, thanks for a fruitful discussion and thanks everyone for their input. |
@skyrpex value object equality is different from PHP object equality. |
|
Took a bit longer than expected, but the package is now called |
Cool!
|
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?
The text was updated successfully, but these errors were encountered: