[TYPO3-50-general] FLOW3 and DDD

[Nino Martincevic]

Sorry people.
But this is a No-No-No, really.
Don't do it.
Never.

(Ok ok, this is demonstrative but this issue is too important)

Robert Lemke schrieb:
> Take a person: Each person is unique, for sure. But what identifier lies
> in the domain of a Person? Surely no UUID. Usually you'd identify a  
> person
> by the combination of certain properties, such as last name, first name
> and birth date.

This depends heavily on the domain.
If you take these three above attributes then how you would distuingish 
a person with a common name, say "Peter Schmidt" born on the same day 
like another one?

Is it important for you?
No? - then go!

Yes? - If you are a bank, is it enough if I only tell you my name and my 
birthdate?

You see?
Maybe it was not enough for an relevant identity.

Hm, there is a nice story about this but I forgot the link.
Basically it's a real-world example of how identity could be misused by 
querying the wrong or too few attributes and not combining and checking 
them.

Most banks need also a signature or a telephone PIN if I call them.
That is an identity for them, the other is simply not enough in their 
context.

>   - while it is transient, an entity is identified by its PHP object  
> hash
>   - as soon as it has been persisted, it is identified by its UUID
> 
> But that happens behind the scenes and with good reason ...

Sorry but you are misusing the domain again in favor of some 
persistance-related identity again!
A hash is nothing else then a database id. This is technical and created 
by the system not by the domain, it has no meaning in it.
Therefore it is not a part of it.

A good exercise and rule of thumb is:
what if you merge your data with another system or you distribute your 
objects?
Will your DB-Id, a hash or some other non-domain-relevant identity be 
enough to compare objects and to distinguish them?
In most cases no....

For a more important reason: see below.

>>> So, the example should read:
>>> $customer = new Customer(12345); // where 12345 is the identity,
>>> something like UUID
>>> ($addressRepository->find(bla, blub);)
>>> none found
>>> $address = new Address(bla, blub); // again "bla/blub" is identity
>>> $customer->setAdress($adress);
>>> $customerRepository->add($customer);
>>> $persistenceManager->persistAll();
> 
> I don't agree. You can create two Customers with exactly the same
> properties which have separate identities:
> 
> $customerA = new Customer();
> $customerB = new Customer();

Can you exist as a copy in realtime?

If it doesn't matter that you work on a copy it doesn't matter.
But if you have domain-relevant entities it always matters.

Although PHP is a transactional thing it helps very much to think of 
in-memory collections. And how can one identical object exist twice, 
that's always a copy. Now change one....

It is not that hard as it seems.
Just find a identity in you domain model, either in the application, a 
service or where ever, construct an entity with iot and voila.
No problems anymore.

This is shifting liability from technology to yourself. But this is what 
counts. The memory is ignorant if it works on a copy or not.
But if you are banker and give money or loan a wrong person, well you'd 
have a problem then, I'll guess...

So what have you gained by giving a id/hash by some peristance mechanism?
Nothing!
Because at least at "save-time" you'll get a problem you otherwise would 
not even have.

Nino