[TYPO3-mvc] Persistence of value objects

[Jochen Rau]

Hi,

I just published some more detailed explanation on my blog:

http://blog.typoplanet.de/2012/04/19/difference-between-entity-and-valueobject/

It's intended to reach a broader audience. I don't want to duplicate
discussions.

-Jochen

On Thu, Apr 19, 2012 at 10:01:35AM -0400, Jochen Rau wrote:
> Hi,
> 
> I would like to propose a more radical approach: What if we drop the
> whole distinction between Entity and ValueObjects?
> 
> 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.
> 
> Let's take the color "red" for example. It doesn’t matter which "red" we
> assign to a product. It's always "red". So, we create a ValueObject with
> the property $value="red".
> 
> Following Eric Evans, we don't assign an intrinsic identity to the
> ValueObject. Instead we take the hash over all property values.
> 
> Now the problems arise. We want to output the color in French instead of
> English. Is the color "rouge" different from "red". Well, yes, uhm, no.
> In fact there are two things here: the concept [1] of red and the
> different representations of red ("red", "rouge", "#f00", etc.).  In my
> opinion, the abstract concept and the different representations are all
> Entities (with their intrinsic identity). The only difference is, that
> the representations refer to the abstract concept. If we want to assign
> a color to a product we should always assign the concept to it, not a
> representation. If we serialize the product to a representation (say in
> HTML) we determine the best representation for the given context (format
> HTML, current date and time, language, etc.).
> 
> 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).
> 
> 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?
> 
> Best
> Jochen
> 
> [1] There is a joke about the concept of Jochen. I don't like it.
> 
> On Wed, Apr 18, 2012 at 03:07:51PM +0200, Dennis Ahrens wrote:
> > Hi list,
> > 
> > i currently try to change my domain model for a person. Therefore
> > i'd like to make the assigned addresses a value object, because
> > there are many instances with the same address and i don't care
> > about all existing addresses.
> > 
> > When monitoring the database i've noticed that same addresses were
> > saved as seperate instances, with a uid etc.
> > 
> > To verfiy this, i've installed the blog_example and had a look at
> > how tags are persisted. It behaves in the same way.
> > 
> > It looks as if they are handled in the same way like entities, is
> > there a reason for this behaviour? I guess this is not the intended
> > way, is it?
> > 
> > I'm currently using extbase 1.4.1 with some cherry picks, which
> > should not affect this part of persistence.
> > 
> > regards
> > Dennis