[TYPO3-mvc] Persistence of value objects

[Dennis Ahrens]

Hi Jochen,

On 19.04.2012 16:01, Jochen Rau wrote:
> Hi,
>
> I would like to propose a more radical approach: What if we drop the
> whole distinction between Entity and ValueObjects?

In the past i had problems to identify value objects at all. The main 
problem for me was the connection to the database and the way TYPO4 v4 
handles persistence.
"Why the hell do they have a uid? Okay, without uid -> no relation - 
makes sense... But why do i distingush than? Ah, of course, because they 
do not really have an identity - but with a uid they obviously have... 
strange..."
As i don't really get the point of how extbase handles the stuff and 
what it means there at all i always decided to use entities.

> Recently I spent some time thinking about the difference between these
> two DDD building blocks. I came to the conclusion that there is none.
> Eric Evans argues from a technical standpoint. The promise is, to
> differentiate between Entities and ValueObjects will lead to a
> performance gain and a simpler system. In fact it is quite the opposite.
> And from a Domain perspective, we don't need to make such a distinction.

Just read the part in Evans book again and i disagree that there is no 
difference in general. From the conceptual point of view the disjunction 
of both building blocks makes sense.

But in fact we are in the world of PHP where the runtime is always just 
one request and we have to persist everything at the end of each 
request. In this environment the value object is not cheaper than the 
entity - we have to query the database for an existing instance. But it 
is also not much more expensive, it's "just" +1 query (and if the query 
matches an object it's equal).

> Color is probably a bad example. How about an address, a number, a name?
> I found no difference here. It's just the wrong way to cut the Domain
> into two. The line to draw is between abstract concepts and their
> concrete representations (aka non-information resources and their
> representations).

I currently identified my first value object that makes sense IMO - let 
me explain what and why i think that it makes sense to use a value 
object here instead of an entity. I stick near to the TYPO3 universe...

One Person have 0..n addresses. There are a few thousand instances that 
share five different addresses, because they belong to our university 
and work at one or more of our locations. In addition any other external 
person can be added with any address.

If we make addresses an entity we *must* have set of all addresses our 
editors have to take care of, if we'd like to keep the number of 
redundancy addresses small.

Editors can not just add a person, entering a few addresses and save. 
They have to search for existing addresses to add or create new. If it's 
modelled to reach this using IRRE we'll have a few thousand objects in 
the database that cover the same address with just different uids.

This may lead to performance issues, if we make a findAll on the person 
repository, there are much more object instances in memory, when we deal 
with entities, as if we deal with value objects in this scenario (except 
the way to take care of all addresses).

> So, I propose to deprecate the use of ValueObjects. In addition, we
> should come up with some guide how to model the domain with the
> distinction between concept and representation in mind.
>
> What do you think?

I think that in general it makes sense to distinguish between both 
object types. I also think that it is a big task to tackle TCEMain. 
Using hooks to match the requirements of value objects is not reliable IMO.

But you are right, that it does not make sense to stick to a conceptual 
approach, just because it exists. :) If nobody uses it, we might drop it 
(as it does not seems to be a big problem in the past, that they can't 
be handled by TCEMain).

I do not follow the FLOW3 project that closely - but in general extbase 
should go into the same direction.

regards
Dennis