[TYPO3-50-general] FLOW3 and DDD

[Nino Martincevic]

Hi Robert and Xavier,

coming back to this thread. Some things did not let me sleep and should 
not be left as they are, because they are simply confusing or bogus.

>>> I don't agree. You can create two Customers with exactly the same
>>> properties which have separate identities:

You know what a paradoxon is? ^
;-)
If ALL their attributes are equal (including the DNA if we are creating 
a medical software) how can they have separate identities?
At least we need ONE attribute (not an artificial one, that would be 
like someone asks two people for they distinction and they invent a 
number) that isn't equal - ortherwise they are value objects.
Sorry, but this is not understandable (in fact in a hospital or banking 
software this would be criminal...).

One important question was not answered yet:
Where or how do you create a customer with "new Customer()"?

If it's in your application layer (e.g. controller) then you bypassed a 
bunch of domain model logic, domain and invariant/rule checking. What if 
such an object is an entity inside an aggregate and therefore cannot be 
created and accessed outside of it but only through querying the 
aggregate (root entity)?

I would kill my developers if they'd do something like that and would 
not utilize a provided Facade for creating domain objects...

And even then you would not create with "new DomainObject()" but have a 
factory for this. That's the pattern and the concept (of Evens) that
apparently creates objects, they don't create themselves.

With that method you could create two dumb Customer objects (DTOs) as 
simple data holders, yes. But not valid domain model objects.

>>> $customerA = new Customer();
>>> $customerB = new Customer();
>>
>> Can you exist as a copy in realtime?
>>
> We have an identity map for that.

An identity map is, well, a map of identities. But of stupid "objects" 
(every new Object() is stupid and useless) not "entities" or domain objects.
Where would you query for them if you have e.g. a MVP and the presenter
has to send soemthing to a distinct one?

> We need the uuid and object hash for the unit of work and identity map.

That's all fine. But this is a Hibernate- or ORM-like solution of 
managing objects, Database (i.e. Persistence) not Domain.
You don't need DDD for Flow3 but you can't use DDD that way either.
For other design it should be fine.

The basic idea of entities, that they only have one way of being 
accessed (because they only have one "life" or representation), no 
matter how you call it and therefore can guarantee uniqueness/identity, 
is cheated hereby.

 > But that has nothing to do with DDD itself.

That's right.
But if you want to support and promote DDD you should not make people 
think that a persistance and caching solution camouflages bad design. I 
suppose you don't but one could not be careful enough, the latest drift 
at Zend warned me...

We had that long enough in the PHP world, and I'm not excluding myself 
here, but writers and software developers who sell their products also 
should bear responsibility for what they do, say and propagate.
Everybody knows singletons so where's the problem with learning the 
concept of identity & entities?

And after all: hey man, I wanna use that stuff, so make it work right, 
good and fast!
;-)

cheers,
Nino