[TYPO3-50-general] FLOW3 and DDD

[Xavier Perseguers]

Hi Robert,

Seems that I understood the creation of new object in domain the same as 
you, I mean with the PHP object hash as long as it remains transient. 
But I understand Nino's point of view too...

Anyway, I'll continue keeping an eye on this list ;-)

Xavier

Robert Lemke wrote:
> Hi Xavier,
> 
> Am 19.01.2009 um 16:14 schrieb Xavier Perseguers:
> 
>>> You forgot to mention that in Nilsson example there is only "create
>>> new", but create new Customer means create one with clear identity.
>>> Without it: how can you add it to the repository when you don't know its
>>> identity, how will you get it back? Therefore you first have to check if
>>> one with that identity exists (via a repository).
>>
>> This sounds OK but do you mean that this is not repository's work to
>> provide an ID/identity? I mean I do not need any identity (I understand
>> identity as the auto-increment field in a DB) to work with my domain, I
>> just need "pointers". That is when I "create" a new Customer. I have to
>> provide it's first name, last name and perhaps a business id if I need
>> it but albeit from that, a new customer does not have any identity or
>> business identity until it is persisted. I don't want to reserve a free
>> id (auto-incremented in MySQL) from the DBMS nor do I want to create a
>> business id (thus not in relation with DB-stuff) until I do something
>> useful for my business with this customer. That is for the business ID
>> until it orders something for instance.
> 
> Correct, the Domain Model (usually) does not know about the technical
> details of its identity.
> 
> 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.
> 
> The Person domain model doesn't know that the Content Repository is using
> a UUID to identify the person. And it doesn't care when this happens.
> 
> In fact the identity of an Entity is managed by two authorities:
> 
>  - 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 ...
> 
>>> 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();
> 
> Of course, in case of a customer it is wise to introduce some property
> which makes identification (within the domain) easier, for example a
> customer number.
> 
> But that customer number exists idenpendently from the object's UUID.
> 
>> That is you must generate an ID for all "new" customers regardless of
>> whether they will be persisted later? I do not understand. If you
>> generate a UUID, that's fine, it's unique by design but what if you use
>> a sequential business number?
> 
> exactly.
> 
> Cheers,
> robert


-- 
Xavier Perseguers
http://xavier.perseguers.ch/en/tutorials/typo3.html