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

[Nino Martincevic]

Hi Martin!

Martin Kutschker wrote:
> Nino Martincevic schrieb:
>> +1
>>
>> I also don't have a suffix for Models, just because they are the
>> important things, mentioned in the UL, that should not be diluted by
>> merely technical suffixes - latter ones are ok for the infastructural
>> parts of the domain.
> 
> Do you (or would you) suffix other classes that are not inside the model
> directory?

In my current project (with a quite complex domain model), yes.
Well, most of the time :-) I also try not to suffix generic types used 
also outside the model, like Money, Party, etc.

But as I explained in my other post, that does not really matter - or is 
a matter of taste. It's more important to bundle things into Modules 
(the DDD concept) that do often reflect Bounded Contexts, like 
Invoicing, Shipping, Ordering. Then you have the same prefixes for your 
files and they do reflect the context and avoid the problem of reserved 
names.
The only problem here is that you may have classes with the same name in 
more than one module/model - namespaces to rescue!
Without namespaces you have to accept the limitations of your framework 
or language - don't fight them.

Actually even putting all files in one directory that belong to one 
context (model) and the same layer is not a bad thing.

An object "ShippingSpecification" does not change its concept if its 
location changes, so it's not important to have a folder/file hierarchy 
if it doesn't offer a real benefit.

Another thing are the technical and logical boundaries, like layers.
A "clean" layer should have clear interfaces and its own place. When you 
develop a large app you normally have people working on the Application 
(Service) layer, other on the UI layer and the third on the domain.
Separating them makes it possible to work independently on them.
Also legacy apps and layers do play a large roll: in the above mentioned 
current project I do have classes named ...Model, the ORM classes.

But there are other, more or better suited scenarios, depending on your 
project needs, specifications or taste. Many ways lead to Rome.

Cheers!