[TYPO3-50-general] FLOW3 and DDD

[Robert Lemke]

Hi Nino,

we both know the books, we're talking about the same, but I've got the
feeling that you misinterpret my mails. What you write about DD is  
certainly
true, but it doesn't contradict what I wrote or how it is implemented  
in FLOW3.

Am 19.01.2009 um 17:59 schrieb Nino Martincevic:

>> - 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!

Nope, I don't. I explained how the persistence mechanism works. This is
all transparent to the domain.

> 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....

sure, sure, but that's what I wrote.

> 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....

We have an identity map for that.

> 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.

We need the uuid and object hash for the unit of work and identity map.
But that has nothing to do with DDD itself.

Cheers,
robert