[TYPO3-50-general] FLOW3 and DDD

[Xavier Perseguers]

Hi Nino,

Thanks for your explanation.

Cheers
Xavier

Nino Martincevic wrote:
> 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
> 


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