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

[Nino Martincevic]

Hi Irene!

Irene Höppner wrote:
>> You don't have to explain Repositories or Services to domain experts  
>> (Customers).
> 
> Hi Nino,
> 
> that's exactly the reason, why i think about separating them from the  
> model i want to discuss about. I guess (I don't know), that, if they are  
> in the same folder, I'll either have to say "just ignore them" (and  
> they'll think about them though) or I'll have to explain. Because they'll  
> (hopefully!) ask, what that is.

Hm, perhaps we have to define what exactly you mean by "discuss with 
customer"? Do you discuss the code, does your customer want to read the 
code? Not really, do they? If yes you have to explain quite a bunch of 
stuff to them...

In your last post you said:
"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."

The customer has not to understand the *code* but the code has to 
reflect the customer's concepts, the Ubiquitous Language (key concept of 
DDD!) you gonna develop with him and the whole team.

You don't talk of Repositories with him, he doesn't need to know that a 
ShippingItem is an AR that is being retreived by a Repository.
They are not interested in such specific backend and technical things, 
they want to know if all the processes they talk about are reflected in 
the software, not how and what patterns you use.

And the benefit of DDD (it's not really an invention of DDD) is to have 
code that reflects the domain (the domain is not the software).
Then you could draw diagrams (even UML) and discuss it with the customer 
and everybody talks about the same. I.e. if you both talk about a 
shipping specification of a shop item, the diagrams reflect the concept 
of a shipping spcification for an item and the code has a 
ItemShippingSpecification etc.

It is a great benefit compared to "old-school" techniques where all 
stuff has technical or cryptical names. Some of my customers do not have 
a problem reading UML sequence diagrams, because all terms therein are 
well-known in their own language.
You won't see the word "Repository" there :-)

Cheers!