[TYPO3-50-general] Last minute concept fix? Incosistent class naming for domain models ...

[Nino Martincevic]

Irene Höppner wrote:
> I'm not very familiar to DDD yet, but as far as i remember it is about  
> writing code, that the customer understands too, even, if he has no IT  
> Background.
> With that in mind, i like the ide of separating the repository and the  
> model.
> If I imagine to show the above structure to a customer - maybe asking, if  
> the model is complete, i would have to explane, what a repository is, why  
> the comment and the tag is in the post etc.... while with robert's first  
> idea, i'd just open the folder model and keep the folders repository etc.  
> closed. With this structure i would have to say "ingore the ...Repository  
> and ignore the ...Service". This is pretty hard for not-programmers.
> 
> Just an impression...

You don't have to explain Repositories or Services to domain experts 
(Customers). These are DDD "patterns" that help to fulfill a business 
need. You only talk about business concerns and models, not how they are 
implemented.
You also would not explain SQL queries to them, would you?

And to all other posters: keep in mind that Aggregate Roots are one of 
the most important concepts of DDD. And aggregate roots are always 
consistency boundaries.

The other very important concept is the "Bounded Context", so you 
normally don't have only one "Customer" model but a PreferredCustomer, 
AspectedCustomer, NewCustomer etc. model.
E.g. the invoicing department is only interested in customers who have 
outastanding bills etc.

So spanning similar objects between different models is something very 
normal and important. Think of roles not classes, because all object do 
play a role in a given context.
[Btw: It's OOP not COP ;-) ]

Therefore it's very hard to base the file structure on singular classes.
Perhaps it's more intuitive to organize them by context.

My $0.02

Cheers
Nino