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

[Nino Martincevic]

Hi Martin!

Martin Kutschker schrieb:
> Ah, now thing's are getting interesting. Until now I though that DDD is
> just another nice way to have your code organized. Being able to discuss
> the software creation process with a layman with a shared vocabulary
> sounds like a dream.

Well, no dreams without nightmares ;-)

That is really one of the most important things you gain from DDD.
Not without reason, the ubiquitous language is the first concept you 
learn when first dealing with DDD.

The whole benefit is easy to grasp:
Instead of having to translate another layer of abstraction, the one 
between those who have the business/domain and the developers, you talk 
the same language and BOTH gain much more insight into the domain.
Each side into things they either didn't catch right, didn't understood 
right or stuff that is not easy to grab. How you could grab it by having 
additional complexity with translating into non-ubiquitous terms and names?

So far, so good.

BUT:
This thread is somewhat misleaded by the initial example.
A Blog is almost never a good application example to be done with DDD.
DDD is only suited for complex projects and almost 90% of web projects 
don't fall into this category but are merely CRUD application with a 
little or no behaviour in it.

That's not bad, but developing such apps with DDD is a pain in the a**.
Because DDD definitely has overhead and a high and practically a never 
ending learning curve.

So, if your app is doing mostly CRUD and has classes that are almost all 
only data containers and have no or very few behaviour in it, simply 
don't do it.
That said, though you CAN take single concepts of DDD that are suited 
for other kinds of apps. Some concepts/patterns are really helpful in 
any kind of apps, like ARs and repositories, because they are simply a 
good instruments for doing clean OOP.
But if you follow a strict path, you will have more pain than gain.

What does all has to do with the initial thread?
That above break explained most of it: primarily CRUD apps could ( a 
probably should) have a class structure that reflects the data-centric 
view on it.
But complex DDD-apps almost never have a static structure based on data.
Data is not important to DDD, context and behaviour is.
It changes often as the insight into key concepts, generated by 
discussions with the domain expert(s).

And I guess you don't want to base the view and knowledge of the app on 
a directory structure that changes often or constantly.
Maybe one day a ShippingItem is located under Order (assuming these are 
either classes or files), some months later it is recognized as a key 
concept of a new Shipping (department) context.

This are extreme examples, it's not always radical like this but you 
should be aware of that.

Not very satisfying for people who like clear structures but the more 
complex systems/domains are the more flexible your code has to be.

The only constant thing is change.


Cheers!