[TYPO3-50-general] FLOW3 and DDD

[Nino Martincevic]

Hi Xavier!

Xavier Perseguers schrieb:
> 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) 

That's the problem.
You don't think of database, file, soap, stone plate or other 
persistence "backends" in DDD, the only thing that counts is the DOMAIN.
Forget it. It never existed.
As a real person, do you think of being "persisted" somewhere?
I know real world is not software but it helps sometimes.

And I also that's one of the harder parts when starting with DDD but a 
littler later things gets easier :-)

It depends on your domain and context which identity an entity has.
E.g. for some real-world "entities" there exists globally unique 
identities, like for cars their identity number on the body or the 
engine number.

If e.g. for your domain you distinguish a Customer by a customer number.
Does your database gives you this number, you also use on the accounts?
Is it "1", "122" or something like "C10001-DE"?

People, at least in germany, have also a unique social security number.
Maybe that's enough for your domain to ensure unique identity.
But what with people that do not have such a number?
Or what if it changes, like a few months ago here in germany.
Can your domain still distinguish them and work like expected?
These examples are from Evans, Nilsson and my experiences.
Evans also ask's "Who is asking?" as a sidenote, meaning for one context 
it matters for another not. Address is a very popular candidate for 
entity/value object discussions...

You may see, it depends on your domain if an identity may be simple or 
not. If it's critical you have more work to establish an identity.

Or you take somtehing artifial as Identity (but not from the DB!), a 
very practical one, used in the .NET world is a GUID (or UUID in PHP).
That way you could create a Customer even on start without any 
attributes, by providing a service that creates a Customer with that 
GUID. Then you can work with it.
But keep in mind that the identity is solely artifical and could cause 
some other problems.
[Some people (like me) just use more then one identities. One for the 
persistence that is never needed in the application and one for the 
"real" identity in the domain.]


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

No, you must generate Identity, not an "autoincrement ID".
What is *your* identity, Xavier Perseguers or 12000282828?
(well I guess, your DNA is...)
;-)

How you could reference somebody and ensure that he is unique who has no 
identity? Yes, you could use the UUID, like I said before.

But it's easier:
Because you want to work with entities that "make sense" and are 
relevant in and to your domain, give them the identity they should have.
And save it at will. The auctoincrement Id may be then 233444, so what?
You don't have a repository method finByMysqlId() but 
find(ByIdentity)(). The latter could also be a cpmplex object or a 
specification.

Hope it's a bit clearer now.

And I can not state it often enough: If you have the chance to do it 
from the scratch, forget the DB, concentrate on DOMAIN.

Cheers,
Nino